The Artima Developer Community
Sponsored Link

Weblogs Forum
The fate of reduce() in Python 3000

119 replies on 8 pages. Most recent reply: Dec 18, 2018 1:39 AM by Claudemir Moliane

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 119 replies on 8 pages [ « | 1 ... 5 6 7 8 ]
bug not

Posts: 41
Nickname: bugmenot
Registered: Jul, 2004

Re: The fate of reduce() in Python 3000 Posted: May 1, 2006 2:55 PM
Reply to this message Reply
Advertisement
..ups, i didnt saw guido´s post saying tht lambda will prevail.
Thats great. ¿but what about filter, map and reduce?

Gene Sullivan

Posts: 1
Nickname: gene13322
Registered: Jan, 2007

Re: The fate of reduce() in Python 3000 Posted: Jan 9, 2007 1:06 PM
Reply to this message Reply
Wouldn't the removal of such functional programming functions make it harder to port programs written in Lisp, Scheme, Logo, and other such so-called `functional' programming languages more difficult if not (im)practically impossible ... as well as programs written in C, c++, or C# which employ the functional style of programming {ref: http://okmij.org/ftp/cpp-digest/Functional-Cpp.html}?

Is functional style programming to be maimed out of existence by lopping off a functional limb at a time until this style of programming is no longer viable?

What's up with this?

Constantin Svintsoff

Posts: 1
Nickname: mrv1
Registered: Jan, 2007

Re: The fate of reduce() in Python 3000 Posted: Jan 12, 2007 8:14 AM
Reply to this message Reply
Removing language constructs (lambda) is a sabotage against users. There is no way (or I do not see any) to make "old" code working when you remove lambda completely without wasting human time resources amount proportional to the size of project. You can define own reduce, you can't define own lambda. Doing such a things without worthy reason (the fact that using lambda may produce hard to understand code - cannot be considered as worthy reason. Any languagy construct may be misused.) - is wrong.

luke kenneth casson leighton

Posts: 1
Nickname: lkcl
Registered: Feb, 2007

Re: The fate of reduce() in Python 3000 Posted: Feb 28, 2007 1:50 PM
Reply to this message Reply
one of the beautiful things about python is its compact
expression.

the functional programming aspects - map, reduce, lambda - are fundamental parts of that compactness and beauty.

millions of lines of code - complex code, written by experienced mathematicians and physicist - will need to be thrown out the window if python loses that functionality.

it is possible to emulate a parallel computer with map, reduce and lambda.

such that (and i did seriously consider doing this) it is _also_ possible to then do an implementation of those builtin functions on accelerated parallel hardware.

and, yes, such suitable parallel hardware DOES exist: from a company called 'Aspex Microelectronics'. they do a massively parallel array-string processor (SIMD - but not 32 processors, not 64 processors - 4096 2-bit processors with 256 bits of content addressable memory on each 400mhz processor, and the next generation is to have 65536 2-bit processors, at probably 600 to 800mhz)

so.

the thing is: reduce and map could go as 'builtins' and you can write those as functions - but lambda certainly can't go.

removing lambda would be like removing one of the legs of a stool: it will fall over.

Byron Formwalt

Posts: 2
Nickname: bformwalt
Registered: Nov, 2007

Re: The fate of reduce() in Python 3000--what about lambda?! Posted: Nov 3, 2007 6:53 PM
Reply to this message Reply
List contexts are sufficient to replace many uses of the lambda inline function definition capability. There is one significant annoying consequence of eliminating lambda, however. Without this capability, it becomes more cumbersome to pass a custom cmp() definition to sort().

Byron Formwalt

Posts: 2
Nickname: bformwalt
Registered: Nov, 2007

Re: The fate of reduce() in Python 3000 Posted: Nov 3, 2007 8:25 PM
Reply to this message Reply
> I have a list of some records. With lambda I can do:
>
> my_list.sort(key = lambda x: x.name)
> # or
> my_list.sort(key = lambda x: x.age)
> # or
> my_list.sort(key = lambda x: x.address)
>
> Can I sort list by different keys very easy without lambda?

I think you'll have to define nested functions just prior to calling sort with the key argument. Without lambda, it just can't be done anonymously. The alternative is to make your own python extension that implements sort differently. If sort was implemented so as to order one list (data) according to the default ordering of a second list (keys), then you could avoid the need for lambda altogether when performing custom sort operations. Below is an example I entered into the python command-line interpreter.


[formwalt@transport:~] # python
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def fn():
... def fn_name_key(x):
... return x['name']
... def fn_age_key(x):
... return x['age']
... def fn_address_key(x):
... return x['address']
... bob = {'name':'Bob','age':23,'address':'somewhere'}
... alice = {'name':'Alice','age':54,'address':'nowhere'}
... phil = {'name':'Phil','age':30,'address':'unknown'}
... my_list = [bob,alice,phil]
... print "Original List: " + str(my_list)
... my_list.sort(key = fn_name_key)
... print "Sorted by Name: " + str(my_list)
... my_list.sort(key = fn_age_key)
... print "Sorted by Age: " + str(my_list)
... my_list.sort(key = fn_address_key)
... print "Sorted by Address: " + str(my_list)
...
>>> fn()
Original List: [{'age': 23, 'name': 'Bob', 'address': 'somewhere'}, {'age': 54, 'name': 'Alice', 'address': 'nowhere'}, {'age': 30, 'name': 'Phil', 'address': 'unknown'}]
Sorted by Name: [{'age': 54, 'name': 'Alice', 'address': 'nowhere'}, {'age': 23, 'name': 'Bob', 'address': 'somewhere'}, {'age': 30, 'name': 'Phil', 'address': 'unknown'}]
Sorted by Age: [{'age': 23, 'name': 'Bob', 'address': 'somewhere'}, {'age': 30, 'name': 'Phil', 'address': 'unknown'}, {'age': 54, 'name': 'Alice', 'address': 'nowhere'}]
Sorted by Address: [{'age': 54, 'name': 'Alice', 'address': 'nowhere'}, {'age': 23, 'name': 'Bob', 'address': 'somewhere'}, {'age': 30, 'name': 'Phil', 'address': 'unknown'}]
>>>

ian o

Posts: 8
Nickname: iano
Registered: Aug, 2007

lambda and def Posted: Nov 19, 2007 1:42 AM
Reply to this message Reply
I do realise the topic has between returned from the grave to discuss lambda well after it has all been resolved to keep lambda..... at least until 4.0....

but.....

given that features can only be removed for a x.0 release it is not the time to discuss removals anymore it is back to new features.

So we still have lambda and def which have some similarities.

double =lambda (x):x*2
is equivalent to
def double(x):return x*2

I would suggest that either def should be converted to an expression (which would allow deprecating lambda as a separate solution in the future) or multiline lambdas be allowed (which strangely could allow getting rid of def if we wanted a single solution?)

making def an expression would allow

double=def foodub(x):return x*2

inplace of lambda. The 'foodub' name could be optional for real compatibility where the name is superfluous but even though effectively a comment could aid readability in current situations..
e.g. setHandler(def handler():return 1, .....
More importantly there would be a syntax allowing multiline 'lambdas' which there is definitely some call for.

Which to people consider more in keeping with the rest of python....

double =def(x):return x*2
or
def double(x):return x*2
?
To avoid still needing lambda perhaps the a compiler option for single line defs to return the expression? Unlikely to break many programs and would allow
lambda=def
to keep old code working

Of course the other idea is to go the other way and allow multiline lambda using the same detection of single vs multline used elsewhere in the language, only allowing termination with ) or , in addition to resetting indent

Any thoughts?

Paul Masurel

Posts: 1
Nickname: fuliculi
Registered: Jun, 2008

Re: The fate of reduce() in Python 3000 Posted: Jun 22, 2008 10:03 PM
Reply to this message Reply
I was about to cry the loss of reduce but after reading your article I understood that I was wrong on many point.

You're right that reduce with strange operator is making code more difficult to read, and you're nice enough to offer the any and all function that where actually my favorite use of reduce.

What about concatenation? Here is a pretty frequent pattern:

res=[]
for c in possibles:
res.append( solve(c) )
return res

I kind of used to like:
return reduce(lambda c1,c2: solve(c1)+solve(c2), possibles)

old basara

Posts: 1
Nickname: oldbasara
Registered: Jun, 2008

Re: The fate of reduce() in Python 3000 Posted: Jun 25, 2008 12:20 AM
Reply to this message Reply
I started dabbling in python from a C++/Java background and reduce() was one of my instant favorites. I just loved to show this snippet when showing anyone the conciseness of python.


def fact(n):
return reduce(lambda x,y: x*y, xrange(1, n+1))


Yes I could do that with a loop but eliminating loops was what I liked and used to illustrate using that snippet.

It seems sad and ironic that some of the things that drew me to python are not going to be there in Python 3000.

Steve Witham

Posts: 1
Nickname: pygme
Registered: Nov, 2008

Re: The fate of reduce() in Python 3000 Posted: Nov 11, 2008 7:53 PM
Reply to this message Reply
I'm a fan of lambda and reduce, but I feel that in Python:

Fewer ways of expressing something is better than one of them being terse.

Making sense to relative beginners is more important than being natural to people who know math or lisp.

Even though it's a good thing, even though it will be kept, if lambda is being used a lot as a band-aid, a patch on a problem in something else, people ought to think of it as a symptom rather than a feature. That is, the fact that you can wire around problem X with lambda isn't a point for lambda so much as a clue to do something about problem X.

Also, if there are speed differences between different ways of expressing the same thing, that's not a point for the "faster syntax," it's a place to improve the compiler.

I was going to post one of my favorite reduce cases, but noticed a couple other people posted essentially the same thing:

reduce( lambda total,digit: total*base+digit, digits )

where the meanings of *, + and digit vary by context, e.g. polynomials and their coefficients. I'm not sure why Guido thinks associative operators are the only clear uses of reduce, but this is an associative operator (or, an expression that amounts to different associative operators for different data types).

Here is a way to do map() for multiple arrays in parallel with a list comprehension:

[ f( a[i], b[i] ) for i in range( len(a) ) ]

There's an uglier method if you have a variable-length list of arrays to work on.

Perhaps these syntaxes make sense and address some of the awkwardnesses mentioned:

# Function that just returns:
def squared(x) => x ** 2

# lambda without the word lambda:
foolist.sort( str1, str2 => cmp( int(str1), int(str2) ) )

# lambda with no arguments:
() => x

I like => better than -> because -> implies implies to me. => is like in digital circuit diagrams where a bunch of parallel lines means data and not just a boolean going through.

julio rincon

Posts: 1
Nickname: julior
Registered: Feb, 2010

Re: The fate of reduce() in Python 3000 Posted: Mar 28, 2010 5:28 PM
Reply to this message Reply
I actually kind of liked this functions they allowed me to easily shuffle my work between Scala and Python. Anyway what would be the clearest/cleanest re-implementation of the following function?


def maxf(f, seq):
'''Returns the element of the sequence that has the maximum value after applying the function f '''
return seq and reduce(lambda x,y: f(x)>f(y) and x or y, seq) or None

bug not

Posts: 16
Nickname: bugmenot2
Registered: May, 2005

Re: The fate of reduce() in Python 3000 Posted: Jul 13, 2010 6:26 AM
Reply to this message Reply
> I actually kind of liked this functions they allowed me to
> easily shuffle my work between Scala and Python. Anyway
> what would be the clearest/cleanest re-implementation of
> the following function?
>
>
> def maxf(f, seq):
> '''Returns the element of the sequence that has the
> the maximum value after applying the function f '''
> return seq and reduce(lambda x,y: f(x)>f(y) and x or y,
> y, seq) or None
>


Much better to do this:

def maxf(f, seq):
return seq and max(seq, key=f)


So actually your maxf is already implemented =).

Jeffry Mcdowell

Posts: 1325
Nickname: gadgetsdna
Registered: Dec, 2009

Re: The fate of reduce() in Python 3000 Posted: Jul 15, 2010 5:30 AM
Reply to this message Reply
may be

Wilson Tian

Posts: 1
Nickname: ttt43ttt
Registered: Nov, 2015

Re: The fate of reduce() in Python 3000 Posted: Nov 21, 2015 11:21 PM
Reply to this message Reply
I'd like the reduce() method back. Map() and reduce() are brothers!

Claudemir Moliane

Posts: 1
Nickname: cmoliane
Registered: Dec, 2018

Re: The fate of reduce() in Python 3000 Posted: Dec 18, 2018 1:39 AM
Reply to this message Reply
I understand and agree with! Move it reduce() to functools will be better shrinking relevant functions to load in standard library.

Flat View: This topic has 119 replies on 8 pages [ « | 5  6  7  8 ]
Topic: A Hazard of Covariant Return Types and Bridge Methods Previous Topic   Next Topic Topic: Markdown vs. AsciiDoc

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use