Weblogs Forum - The fate of reduce() in Python 3000

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

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 119 replies on 8 pages [ « | 1 ... 4 5 6 7 8 | » ]

Ryan Lovett

Posts: 1
Nickname: r8t
Registered: Aug, 2005

Re: The fate of reduce() in Python 3000

Posted: Aug 26, 2005 4:15 PM

> 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

I whole heartedly agree. In my opinion, if anything should go its the list comprehensions. (really, why are they necessary?)

Pieter Z

Posts: 1
Nickname: pieterz
Registered: Oct, 2005

Re: The fate of reduce() in Python 3000

Posted: Oct 15, 2005 5:24 AM

Hi,

I'm not a longtime pythoneer too, I just come across it, testet it, and decided to stick a few months ago.

Iam totally amazed by the power of python ;-)
( I did mainly perl before )

But against many of your thoughts, I find filter and map incredibly usefull. I don't want it to go either, and it's not "unclearly" as some think.

Also I remember that filter() is faster than the totally UGLY [x for x in somelist if x].

Next, sure i could rewrite a def for that, but i use filter in a tree iteration heuristic, and remapping is going to slow it down, right ?

What if lists/tuples had a filter() method, which would work so ? Thats a good idea as someone explained !

Robert Kline

Posts: 1
Nickname: bkline
Registered: Oct, 2005

Re: The fate of reduce() in Python 3000

Posted: Oct 19, 2005 6:21 AM

I really don't care that much what happens to any of the others, but *please* don't drop lambda -- this would break a massive amount of code.

phil jones

Posts: 14
Nickname: interstar
Registered: Apr, 2003

Re: The fate of reduce() in Python 3000

Posted: Nov 23, 2005 5:14 PM

I don't even want to imagine what my Tkinter code is going to look like without lambda.

We need some kind of anonymous functions / closures. And "lambda" is well enough known, at least by anyone who's been through a computer science course, not to be too obscure and confusing.

Final thought. I teach a comparative programming language course. For me Python is an excellent teaching language, easy enough for anyone to get into, but I can show all the interesting tricks right up to a functional programming style *before* I have to take my students to Haskell.

If Python didn't have these features there'd be a bigger gulf for my students to get into FP (or rather, I'd probably have to look for some other language)

Ryan Lowe

Posts: 1
Nickname: ryanlowe0
Registered: Nov, 2005

Re: Syntax for "filter only" list comprehensions

Posted: Nov 30, 2005 11:29 AM

How about this for filtering lists? Instead of:

filteredlist = [x for x in alist if x > 0]

or the proposed:

filteredlist = [x in alist if x > 0]

how about?

filteredlist = alist where > 0

Add a where keyword and bypass the temporary variable completely!

Eric S. Raymond

Posts: 6
Nickname: esr
Registered: Jun, 2003

Re: The fate of reduce() in Python 3000

Posted: Dec 8, 2005 7:19 AM

I don't mind reduce() going away; I agree with your argument that it's difficult to understand, and I don't use it.

But I use map() and lambda() heavily. It would break a great deal of my code if they went away.

I don't like cluttering up my namespace with little functions that are only going to be used once, e.g. as callbacks. That's what make lambda useful.

Rafal Dowgird

Posts: 2
Nickname: dowgird
Registered: Dec, 2005

What about non-list sequences? Tuples? Strings?

Posted: Dec 9, 2005 2:33 AM

The current implementation of list comprehensions isn't quite ready to replace map(). Here is why I think so:

[ x for x in (1,2,3)]<>(1,2,3)
[ x for x in "foobar"]<>"foobar"

A list comprehension always creates a list, while map() and filter() preserve the type of the sequence, which I think is better.
So please, make sure the list comprehensions preserve the sequence type.

Rafal Dowgird

Posts: 2
Nickname: dowgird
Registered: Dec, 2005

Re: What about non-list sequences? Tuples? Strings?

Posted: Dec 9, 2005 3:48 AM

> A list comprehension always creates a list, while map()
> and filter() preserve the type of the sequence, which I
> think is better.

Ooops - I just found out that only filter() preserves the sequence type. Minor correction. I still think it would be good to have a way of 'map()-ping' that preserves the sequence type.

Reuben Sumner

Posts: 1
Nickname: reubens
Registered: Jan, 2006

Re: Save map() or show me the alternative

Posted: Jan 25, 2006 1:57 AM

Doing map(f, l1, l2, l3) means running over l1, l2, l3 in parallel and applying f each time with three arguments. I do not know of any equivalent using list comprehension or generator expressions.

Consider a function for taking two strings and computing a string which is the xor of the two strings. Here are three implementations:


def sxor1(a,b):
    return "".join(map(lambda x,y: chr(ord(x)^ord(y)),a,b))

def sxor2(a,b):
    def f(x,y):
        return chr(ord(x)^ord(y))
    return "".join(map(f,a,b))

def sxor3(a,b):
    return "".join([chr(ord(a[i])^ord(b[i])) for i in range(len(a))])

I normally write sxor1. I do not mind sxor2. I do not much like sxor3.

David Conrad

Posts: 2
Nickname: dconrad
Registered: Feb, 2006

Re: The fate of reduce() in Python 3000

Posted: Feb 26, 2006 5:17 PM

> 5. Can we please get a short circuiting ternary
> operator?
>
> It is possible to simulate (one) with a function, but
> we can't short circuit without your help!

Ah, but you can -- but only if lambda doesn't go away.


cond = True

def one():
  print "in one"
  return 23

def two():
  print "in two"
  return 42

def ternary(p, a, b):
  if p:
    return a()
  else:
    return b()

x = ternary(cond, lambda: one(), lambda: two())

Not: one() and two() are only written as functions with side effects so that we can see if/when they get called.

Wrapping the arguments to ternary() in lambdas delays the evaluation of them, and then calling one or the other forces its evaluation. The result is that only one of them is actually evaluated when ternary() is called.

However, I would also vote for the addition of a ternary operator.

Vladimir Goff

Posts: 2
Nickname: xonix
Registered: Mar, 2006

Re: The fate of reduce() in Python 3000

Posted: Mar 1, 2006 3:17 PM

Hello everyone. I beg pardon for my bad English. I was very disapopinted and upset wheh heared about they want to throw away map, reduse, filter and especially lambda... I am nither Lisper nor Schemer... You see, I long time was looking for language that will satisfy all my needs. And I found it - it was Python. Before that I have worked quite close with Pascal, C, Java, Javascript, ActionScript, Java, little Perl, Tcl and PHP.
At that time I learned two programming paradigms - procedure-oriented (imperative) and OOP.
My acquaintance with functional programming began exactly from Python. But as soon I understood the power and elegance of some FP constructions in Python, not to mention the two other paradigms that Python supports, I can't live without them.
I absolutely agree with Pasko Robert, Jamie Turner, Åsmund Ødegård and others. List comprehansions is quite powerful and useful mechanism, but they cant't substitute in full measure map, reduse, filter, that someone called "Three whales of FP in Python". An concerning lambda... I widely use it in my work. Actually I can say that I am missing of full value anonimous functions, where it can be more than one function call, as in lambda. I anderstand that it is some kind of problem, caused by the Python indentation, that doesn't allow to figer the inline anonimouse function body. Also I am missing about anonimous objects... All these possibilities as I know are present in Javascript and ActionScript...
I think that all flexibility and power of Python is based exectly at the fact that Python is at the same time procedure, OOP and FP language. I __do not__ understand how you want to enhance language, excluding from it this useful features? Or you want it to differ more from other languages so it can occupy its own niche? But why???
I think it is better to give a programmer choice to decide wether to use it or not. And if you see the obscure code it doesn't meen that functions are bad, but rather a programmer, who wrote this code... This is my mind.... I beg pardon for my emotional speach if I offende someone..

P.S. If you exclude these features from Python, I or start searching for another language or begin writing my own version of Python or kill myself and my death will be on your soul, Guido... Joke..... :)

P.P.S. Please, don't kill Functional part of Python...

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

lambda lives!

Posted: Apr 20, 2006 11:20 AM

After about a year of attempts to convince people that lambda had to die or be improved, I gave up. Lambda lives. See

http://mail.python.org/pipermail/python-dev/2006-February/060415.html

for details.

Dean Sturtevant

Posts: 1
Nickname: dness
Registered: Apr, 2006

Re: any() and all() are redundant

Posted: Apr 26, 2006 6:39 AM

> > Why not,
> > if True in (x > 42 for x in S):
> > instead of "any" and why not
> > if not False in (x > 42 for x in S):
> > instead of "all"?
>
> Because "any" and "all" have shortcut semantics (they
> return as soon as they can determine the final result).

Really? "in" doesn't have shortcut semantics?

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: any() and all() are redundant

Posted: Apr 26, 2006 4:12 PM

> > > Why not,
> > > if True in (x > 42 for x in S):
> > > instead of "any" and why not
> > > if not False in (x > 42 for x in S):
> > > instead of "all"?
> >
> > Because "any" and "all" have shortcut semantics (they
> > return as soon as they can determine the final result).
>
> Really? "in" doesn't have shortcut semantics?

It does. The real reason is (a) the above code is not very readable; (b) the above code doesn't quite work (or requires an additional bool() cast) if the condition we're testing isn't always returning True or False.

bug not

Posts: 41
Nickname: bugmenot
Registered: Jul, 2004

Re: The fate of reduce() in Python 3000

Posted: Apr 30, 2006 12:55 PM

(atention, crapy english)
I will really miss lambda!!!
y can build the rest by my self but not lambda.
passing a function as an argument and defining it between brackets is so cool!
im just learning to program, and to say that lambda is confusing is kind of ridiculous. its easy.
you shoudent remove something because people are stupid and get confused.
i jus wrote a massive renaming file toy app using massivly map and lambda. here is how most of my methods look like:

def leftCrop(self,num):self.lambdaReplace(lambda x:x[num:])

and lambda replace is:

def lambdaReplace(self,fun):map(lambda x:self.__rename(x,fun(x)),self.files)

and __rename is:

os.rename(os.path.join(self.dir,name) , os.path.join(self.dir,name.replace(name,newName)))

so thand to lambda i can createa une line method that does almost anything i want!, i can make a call to lambdaReplace and create a bizare method form the console without creating it.
its great!
and thet will be gone?!
meybe because im a self tought beginer i dont see how, butt..¿how would a make that without lambda?

Flat View: This topic has 119 replies on 8 pages [ « | 4 5 6 7 8 | » ]

Previous Topic

Next Topic