The Artima Developer Community
Articles | News | Weblogs | Books | Forums
Artima Forums | Articles | Weblogs | Java Answers | News
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 ... 3 4 5 6 7 8 | » ]
Daniel Wong

Posts: 2
Nickname: danielx
Registered: Apr, 2005

Re: The fate of reduce() in Python 3000 Posted: Apr 24, 2005 3:35 AM
Reply to this message Reply
Advertisement
I would really hate to see these features dropped from Python, but that's only because I'm a Schemer ;). Seriously though, I realize that Python isn't generally thought of as a functional programming language, but I hope that Python will continue to provide support for programmers who want to code in a functional style by maintaining these features. Maybe the solution to the weak lambda is to make it stronger (ternary operator anyone?).

Sakesun

Posts: 10
Nickname: sakesun
Registered: Aug, 2003

Re: The fate of reduce() in Python 3000 Posted: Apr 24, 2005 7:28 PM
Reply to this message Reply
> Also, how do you cleanly achieve lists that are a function
> of multiple sequences with list comprehensions? How do
> you do this, for example:
>
> >>> map(lambda x, y: (x, y, x*y), range(6), range(6))
> [(0, 0, 0), (1, 1, 1), (2, 2, 4), (3, 3, 9), (4, 4, 16),
> (5, 5, 25)]
>

Would this work ?

>>> [(x, y, x*y) for x,y in itertools.izip(range(6), range(6))]

BTW, I don't want to loose lambda, map, and filter.

Brian Granger

Posts: 1
Nickname: bgranger
Registered: Apr, 2005

Re: The fate of reduce() in Python 3000 Posted: Apr 27, 2005 2:10 PM
Reply to this message Reply
Others have mentioned the relationship between python's map/reduce functions and Google's map/reduce style of parallelism. While this relationship is not formal, the ideas are very similar.

I do think that this way of thinking about parallel computation is important as it frees developers of parallel apps up from having to worry about MPI calls and such.

I do think that list comprehensions are a wonderful syntax that encapsulates the map/reduce/filter functions in a very efficient manner. But, I do think it is important to look ahead to when more folks will be implementing more developer friendly modes of parallel computation (like Google's map/reduce).

I think that there are two points to make with this in mind:

1. Keeping map/reduce/filter in python encourages developers to implement parallelized versions of these function in python that follow the standard syntax of python, but that run in parallel.

2. It would be even better if the list comprehension syntax could be generalized to make it possible for for developers to write parallelized versions of list comprehensions. Thta would truly be a step forward in parallel computation. This would require some way of overriding what happens when a list comprehension is given. I haven't thought about how this could be done, but it would be very nice.

Brian

Åsmund Ødegård

Posts: 1
Nickname: mandus
Registered: Jun, 2005

Re: The fate of reduce() in Python 3000 Posted: Jun 25, 2005 4:13 AM
Reply to this message Reply
I second that - I use map, reduce, filter and lambda all the time, and removing them from python will render a lot of my code unusable. So please, please, please - leave this stuff in Python!

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: The fate of reduce() in Python 3000 Posted: Jun 28, 2005 1:22 PM
Reply to this message Reply
reduce&company makes me do evil things :-)

print reduce(lambda x,y:x*256+y,map(int,raw_input().split('.')))

Extra credit for figuring out what this one-liner is good for

Girts Kalnins

Posts: 23
Nickname: smejmoon
Registered: May, 2003

Re: The fate of reduce() in Python 3000 Posted: Jun 28, 2005 3:34 PM
Reply to this message Reply
converts IP adresses?

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: The fate of reduce() in Python 3000 Posted: Jun 28, 2005 6:51 PM
Reply to this message Reply
> converts IP adresses?
yep

Pádraig Brady

Posts: 1
Nickname: pixelbeat
Registered: Jun, 2005

Re: The fate of reduce() in Python 3000 Posted: Jun 30, 2005 6:41 AM
Reply to this message Reply
+1 for any, all!

Goopy has something similar with "some", "every":
http://goog-goopy.sourceforge.net/goopy.functional.html

i.e. these would be equivalent:

some(lambda x:x > 42, S)
any(x > 42 for x in S)

Alan Isaac

Posts: 3
Nickname: aisaac
Registered: Jun, 2005

Re: The fate of reduce() in Python 3000 Posted: Jun 30, 2005 1:24 PM
Reply to this message Reply
Here is where I think the discussion has led in terms of primary costs and benefits from a user's perspective.

* map and filter:

- costs: language clutter?

- benefits: sometimes easier to read (examples in thread);
sometimes more succinct (examples in thread)


* reduce:

- costs: enables evil (obscure) code (according to some)

- benefits: often much more succinct and expressive;
math friendly


* inline anonymous functions:

- costs: can be abused to produce needlessly obscure code

- benefits: see extensive listings on this thread--the need seems obvious


* lambda:

- costs: appears ugly or misleading to Python newbies and to the aesthetically sensitive;
any costs of inline anonymous functions (see above)

- benefits: implements inline anonymous functions (see above)


Closing observation: the considerations seem quite different in each case.

fwiw,
Alan

Claudio Grondi

Posts: 2
Nickname: grondi
Registered: Jul, 2005

Re: The fate of reduce() in Python 3000 Posted: Jun 30, 2005 11:24 PM
Reply to this message Reply
I support what was said in the posting.

From my point of view, the smaller the core set of commands available, the better readable and understandable the code, assuming here that all basic commands are already available in the core set.

Specialized commands should go to appropriate modules, so, that is clear, that to understand them one has to study the philosophy of the modules.
What is minimal (as native basic language commands), core (as modules belonging to every distribution) and what is extended (additional modules not distributed along with the basic package) is a question with a usually continuous changing answer depending what are the core needs of the programmers using the language.
I personally will be happy to see 3D objects and manipulation of them along with their 2D pictured shadowed representation, a spell checker, OCR and some basic linear algebra (matrix, tensor operations, systems of linear equations) as native core elements of the Python language.

Claudio

Alan Isaac

Posts: 3
Nickname: aisaac
Registered: Jun, 2005

Re: The fate of reduce() in Python 3000 Posted: Jul 1, 2005 8:43 AM
Reply to this message Reply
> From my point of view, the smaller the core set of
> commands available, the better readable and understandable
> the code, assuming here that all basic commands are
> already available in the core set.


What is the more readable and understandable version of the following?

#evaluate polynomial (coefs) at x using Horner's rule
def horner(coefs,x):
    return reduce(lambda a1,a2: a1*x+a2,coefs)


Thanks,
Alan

Alan Isaac

Posts: 3
Nickname: aisaac
Registered: Jun, 2005

Re: The fate of reduce() in Python 3000 Posted: Jul 1, 2005 11:00 AM
Reply to this message Reply
> i've never been able to grok reduce, +1 for removing that

Isn't that a reason to abstain rather than to vote?
Just curious,
Alan

Steve Morin

Posts: 1
Nickname: azru
Registered: Jul, 2005

Re: The fate of reduce() in Python 3000 Posted: Jul 6, 2005 8:17 AM
Reply to this message Reply
reduce, lambda, map() and filter()

These things just make code more beautiful. One of the best reasons for using python is that the code ends up being such great code. I am not a big lisp user but have found these functions to make code cleaner. I know this is supposed to be a benevolent dictatorship, my one voice with many asks to leave this in python 3000.
Steve

Joshua Knox

Posts: 1
Nickname: jk0rs7gis
Registered: Jul, 2005

Re: The fate of reduce() in Python 3000 Posted: Jul 16, 2005 9:56 PM
Reply to this message Reply
I am probably the least qualified person posting---I've been using Python for only a few months, after a year or so as a content Perl coder.

That said, I cannot see an argument for the removal (or even renaming) of lambda. Lisp is a great language, the language of choice for AI work. There is no stigma associated with lambda, and it is functional: used in both Tkinter and the Visual module, as well as anywhere where an anonymous function is necessary.

Why remove lambda? Doing so would alienate a sub-group of Python users, and potentially reduce the functionality of Python 3k. It is not, as far as I know, crufty. If it is, improve, redesign, rather than remove.

I realize that my opinion is of no particular importance, but this seems like a horrible idea. The Python user community is the language's greatest strength, and arbitrarily removing parts of that beautiful language is likely to erode that community.

Eduardo de Oliveira Padoan

Posts: 2
Nickname: edcrypt
Registered: Jul, 2005

Re: The fate of reduce() in Python 3000 Posted: Jul 18, 2005 4:11 PM
Reply to this message Reply
Shouldn't reduce, map, filter and zip be list methods?

Flat View: This topic has 119 replies on 8 pages [ « | 3  4  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