Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
George Sakkis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Steven Bethard [EMAIL PROTECTED] wrote: Dict comprehensions were recently rejected: http://www.python.org/peps/pep-0274.html The reason, of course, is that dict comprehensions don't gain you much at all over the dict() constructor plus a generator expression, e.g.: dict((i, chr(65+i)) for i in range(4)) Sure, but the same holds for list comprehensions: list(i*i for i in xrange(10)). The difference is historic I guess; list comprehensions preceded generator expressions and so they cannot be removed, at least not before 3.0. I wonder if they will/should be in the language when the constraint of backwards compatibility is lifted. Guido has asked himself the same question. Some developers who love l.c.s are sure they will stay. I am not. I think it might depend on whether they have any real advantages in the context of the 3.0 engine and design, which don't exist yet. IMO they should not (TIOOWTDI, uniformity among builtin data structures, not overwhelmingly more useful than set or dict comprehensions), but there's a long way till that day. Yes. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Agreed, I dislike map and its ilk as well. However, they are handy in some cases. I particularly like the way Ruby deals with this problem. Instead of all these functions, internal iterators and true anonymous blocks are used. Case in point: def gt_than_5(obj): return obj 5 results = filter(gt_than_5, seq) becomes results = seq.find_all do |item| item 5 end This has the advantage of writing less code for the common cases by having them builtin to the class. Instead of everyone needlessly recoding these over and over again, they're implemented in one place. This could be done by defining an abstract class that enumerable objects inherit from. It's not practical, but I can dream, can't I? ;-) Also, you don't have to define a separate testing function. Granted, in this case, the test func is trivial, but when it's non-trivial, you really notice the advantages. Ivan Van Laningham wrote: Hi All-- Tom Anderson wrote: Comrades, I expect tons of disagreement in the feedback, all from ex-Lisp-or-Scheme folks. :-) I disagree strongly with Guido's proposals, and i am not an ex-Lisp, -Scheme or -any-other-functional-language programmer; my only other real language is Java. I wonder if i'm an outlier. So, if you're a pythonista who loves map and lambda, and disagrees with Guido, what's your background? Functional or not? I'm a pythonista who doesn't love them. In fact, even though I've done more than my fair share of lambda Tkinter programming using lambdas, I've never been happy with lambda. And I've spent months inside of Lisp/Emacs Lisp/Scheme, too (I have the world's second largest .emacs file [my friend Andy Glew has the largest], even though I can't use it on Windows;-). I find list comprehensions easier to understand than map, and small named functions or, better yet, class methods, *tons* easier to read/understand than lambda--there are too many restrictions you have to remember. Personally, I find that Lisp its derivatives put your head in a very weird place. Even weirder than PostScript/Forth/RPN, when you come right down to it. I won't miss them, but since I don't use them now, that doesn't mean a whole lot. Metta, Ivan -- Ivan Van Laningham God N Locomotive Works http://www.andi-holmes.com/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Pawe³ Sakowski [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Tom Anderson wrote: def flatten(ll): return reduce(lambda a, l: a.extend(l), ll, []) How would one do that as a list comp, by the way? I'm really not very good with them yet. Not really a list-comprehension based solution, but I think what you want is ll=[[1,2],[3,4,5],[6]] sum(ll,[]) [1, 2, 3, 4, 5, 6] Unless sum knows to typecheck input items and special-case lists and use list.extend rather than list+list, this turns an O(n) operation into an O(n**2) operation. Sum is meant for numbers. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Stian Søiland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 2005-07-06 02:46:27, George Sakkis wrote: So, who would object the full-word versions for python 3K ? def - define del - delete exec - execute elif - else if Objections for the else if might be that it sounds like you can replace else if with else x=94 if you want. Thumbs up for else if because it explains what it is much better than elif. elseif ? Today, on pydev list, in thread Chaining try statements: eltry?, Guido said 'and in fact I sometimes think it was a mistake to introduce elif just to save typing else if.' So maybe this will be reconsidered for 3.0 Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Terry Reedy [EMAIL PROTECTED] wrote: George Sakkis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Still it's hard to explain why four specific python keywords - def, del, exec and elif - were chosen to be abbreviated, Precedence in other languages and CS usage? What precedence ? I don't know of another language that uses def or del at least; even C++ which compared to python is much more terse uses delete instead of del. And in any case, curly braces for grouping statements is much more prevalent in other languages and CS usage but (fortunately) python chose indentation. So, who would object the full-word versions for python 3K ? def - define del - delete exec - execute These three I might prefer to keep. elif - else if This one I dislike and would prefer to write out. I never liked it in whatever else language I first encountered it and still don't. In contrast to the first three changes which would be straightforward, changing elif to else if would add (a little?) complexity to the parser by allowing else to be followed either by a colon (the only choice now) or if, though I don't think this would be a decisive factor. George -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Ron Adam wrote: Yes, I think a different key word would help. My current favorite alternative is to put it in parentheses similar to list comprehensions and use let. (let x,y return x+y) If you haven't already, see: http://wiki.python.org/moin/AlternateLambdaSyntax for other similar proposals. STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
On 2005-07-06 07:00:04, Steven D'Aprano wrote: map(lambda x: if x == 0: 1; else: math.sin(x)/x, myList) And now for the readable list comprehension version: [x==0 and 1 or math.sin(x)/x for x in myList] Now even though I'm into the short-circuiting of and-or and even occasionally have used such masturbation techniques as this, I don't think it qualifies as pythonic. If it was me, I would probably even have written: [x and math.sin(x)/x or 1 for x in myList] -- Stian Søiland Work toward win-win situation. Win-lose Trondheim, Norway is where you win and the other lose. http://soiland.no/ Lose-lose and lose-win are left as an exercise to the reader. [Limoncelli/Hogan] -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Hi All-- Tom Anderson wrote: I understand that the backslash is popular in some ivory-tower functional languages. Currently, a backslash can be used for explicit line joining, and is illegal elsewhere on a line outside a string literal, so i think it's available for this. It would be utterly unpythonic to use puntuation instead of a keyword, and it would make no sense to novices, but it would scare the crap out of C programmers, which has to be worth something. Oh, I don't think so. Don't forget that Perl was written by impatient C programmers. I think scaring C programmers, like giving engineers too much information, is really hard to do. Live by the sword, die by the sword. Metta, int *(*(*foo)())()-ly y'rs, Ivan -- Ivan Van Laningham God N Locomotive Works http://www.andi-holmes.com/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Steven Bethard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] OTOH, I fully agree with Peter Hansen: Really, the name is such a trivial, unimportant part of this whole thing that it's hardly worth discussing. From a certain viewpoint, I would agree. Yet, the word 'lambda' *is* the center of most of the fuss. For beginners, it is a minor issue: learn it and move on. But for some functionalists, it is a major issue. They 'know' that lambda means 'expressionized anonymous function'. And in lambda calculus, it is the main actor. But in Python, lambda only means anonymous trivial function. It is only an expressionized convenience abbreviation for an important but small subset of possible functions. So for years, such knowledgeable people have called for and proposed various syntaxes for 'proper lambdas' or 'true lambdas', saying pretty clearly that what Python has is improper or false. Would there have been so much fuss if the keyword had been 'fun' and the word 'lambda' had never appeared in the Python docs? I strongly doubt it. I also suspect that the years of fuss over Python's lambda being what it is rather that what it is 'supposed' to be (and is in other languages) but is not, has encourage Guido to consider just getting rid of it. I personally might prefer keeping the feature but using a different keyword. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
George Sakkis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Still it's hard to explain why four specific python keywords - def, del, exec and elif - were chosen to be abbreviated, Precedence in other languages and CS usage? So, who would object the full-word versions for python 3K ? def - define del - delete exec - execute These three I might prefer to keep. elif - else if This one I dislike and would prefer to write out. I never liked it in whatever else language I first encountered it and still don't. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Terry Reedy wrote: I also suspect that the years of fuss over Python's lambda being what it is rather that what it is 'supposed' to be (and is in other languages) but is not, has encourage Guido to consider just getting rid of it. I personally might prefer keeping the feature but using a different keyword. Terry J. Reedy Yes, I think a different key word would help. My current favorite alternative is to put it in parentheses similar to list comprehensions and use let. (let x,y return x+y) Or you could just explain lambda as let, they both begin with 'L', and then the colon should be read as return. So lambda x,y: x+y should be read as: let x,y return x+y I'm in the group that hadn't heard about lambda as a function before Python even after twenty years of computer tech experience. I think presuming it's common knowledge is a mistake. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Terry Reedy wrote: George Sakkis [EMAIL PROTECTED] wrote in message So, who would object the full-word versions for python 3K ? def - define del - delete exec - execute These three I might prefer to keep. elif - else if This one I dislike and would prefer to write out. I never liked it in whatever else language I first encountered it and still don't. Terry J. Reedy Interesting, the exact opposite of what I was thinking. I don't use del and exec that often, so the long versions are fine to me. Define is ok for me too because it's usually done only once for each function or method so I'm not apt to have a lot of defines repeated in a short space like you would in C declarations. elif... I was thinking we should keep that one because it's used fairly often and having two keywords in sequence doesn't seem like it's the beat way to do it. Although it could be replaced with an 'andif' and 'orif' pair. The 'andif' would fall though like a C 'case', and the 'orif' would act just like the 'elif'. Actually this is a completely differnt subject reguarding flow testing verses value testing. Else and also would be the coorisponding end pair, but it seemed nobody really liked that idea when I suggested it a while back. shrug Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
I was going to drop the lambda discussion, as it has been going on and on and on, but Terry's comment strikes me as so wrong that it needs to be challenged. Terry Reedy wrote: From a certain viewpoint, I would agree. Yet, the word 'lambda' *is* the center of most of the fuss. For beginners, it is a minor issue: learn it and move on. But for some functionalists, it is a major issue. They 'know' that lambda means 'expressionized anonymous function'. And in lambda calculus, it is the main actor. But in Python, lambda only means anonymous trivial function. It is only an expressionized convenience abbreviation for an important but small subset of possible functions. So for years, such knowledgeable people have called for and proposed various syntaxes for 'proper lambdas' or 'true lambdas', saying pretty clearly that what Python has is improper or false. Would there have been so much fuss if the keyword had been 'fun' and the word 'lambda' had never appeared in the Python docs? I strongly doubt it. People object to the fact that lambda doesn't allow statements. They do this, not because they know about the lambda calculus (I don't!) but because they keep trying to do things like this: map(lambda x: if x == 0: 1; else: math.sin(x)/x, myList) Hands up who thinks this usage case would disappear if lambda was called fun or anonymous_function instead? I also suspect that the years of fuss over Python's lambda being what it is rather that what it is 'supposed' to be (and is in other languages) but is not, has encourage Guido to consider just getting rid of it. I personally might prefer keeping the feature but using a different keyword. Best of all would be if lambda was extended to allow statements, just like a real made-with-def function. Although, I worry about syntax and readability. But then I'm not completely comfortable with the existing lambda syntax either. And now, I shall say no more on this issue. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Steven D'Aprano wrote: Carl Banks wrote: The shamelessness with which you inflated the verbosity of the latter is hilarious. [snip] [ x**2 + y**2 for (x,y) in izip(xlist,ylist) ] Now there's no longer much advantage in conciseness for the map version (seeing that you'd have to define a function to pass to map), and this is more readable. and then, five minutes later in another post, wrote: If you're doing heavy functional programming, listcomps are tremendously unwieldy compared to map et al. Having a dollar each way I see :-) Don't think so. The verbosity I spoke of was your describing the code snippets in English, not the conciseness of the example. map and friends are more concise than listcomps, I wasn't arguing that, except that for the typical Pythonic use of listcomps it isn't much. One listcomp or one call to map is not heavily functional. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Christopher Subich wrote: Carl Banks wrote: Christopher Subich wrote: I've heard this said a couple times now -- how can listcomps not completely replace map and filter? If you're doing heavy functional programming, listcomps are tremendously unwieldy compared to map et al. Interesting; could you post an example of this? Whenever I try to think of that, I come up with unwieldly syntax for the functional case. In purely functional code the results of map/filter/etc would probably be directly used as arguments to other functions, which might make the calls longer than I'd consider pretty. This is especially true with lots of lambda-ing to declare temporary expressions. I suspect you're misunderstanding what I mean by heavily functional. You appear to see maps and listcomps merely as a shortcut for a for loop. You're comparing the map shortcut and the listcomp shortcut and seeing which one's less verbose. In a mostly procedural program which uses functional constructs in isolation, listcomps are going to win most of those battles. Heavily functional programming is a different mindset altogether. In heavily functional programming, things like maps and filters and function applications are actually what you're thinking about. map isn't an indirect way to do a for loop; it's a direct way to do a map. When your mind is focused on applying a function to each member of this list and returning a list of the results as opposed to convenient shortcut to a for loop, map is going to be far superior to a listcomp. And when you're doing dozens and dozens of maps over a large purely functional program, you don't want to write out a listcomp every single time you want to do it. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
On Sunday 03 July 2005 07:05 pm, Erik Max Francis wrote: I personally think that map looks clearer than a list comprehension for a simple function call, e.g. I have to disagree map(str, sequence) This says call a function 'map' on 'str' and 'sequence' Which, syntactically, is not terribly informative. I have to remember: * str is actually a callable * map is a mathematical concept of linking one thing to another. What things? str to sequence? No! Wrong guess. str is the mapping function, and the result is the thing sequence is to be linked to. Now, sure, I know all this, and I learned what map did from the manual, but it's not especially easy to remember. This on the other hand, [str(x) for x in sequence] is practically plain English: call the function str on x, for every x in sequence Other than chopping out a few words, and using the () operator instead of call, it's hard to imagine this being any closer to exactly what you would say to describe the operation. And for most of us, English comes easier than Computer Science jargon. -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Terry Hancock wrote: On Sunday 03 July 2005 07:05 pm, Erik Max Francis wrote: I personally think that map looks clearer than a list comprehension for a simple function call This on the other hand, [str(x) for x in sequence] is practically plain English: call the function str on x, for every x in sequence Other than chopping out a few words, and using the () operator instead of call, it's hard to imagine this being any closer to exactly what you would say to describe the operation. And for most of us, English comes easier than Computer Science jargon. And with a better choice of names than x, that line becomes even more self-documenting. [str(parrot) for parrot in sequence], for example, tells you much more about what is going on than str(x) does. Exactly what, I have no idea... but it says _so_ much more. ;-) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Peter Hansen wrote: [str(parrot) for parrot in sequence], for example, tells you much more about what is going on than str(x) does. Exactly what, I have no idea... but it says _so_ much more. ;-) Yarr! Avast! Etc! -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Carl Banks wrote: I suspect you're misunderstanding what I mean by heavily functional. snip Heavily functional programming is a different mindset altogether. In heavily functional programming, things like maps and filters and function applications are actually what you're thinking about. map isn't an indirect way to do a for loop; it's a direct way to do a map. That's true; I'm more comfortable with procedural programming in general, but I had a few classes that used LISP and understand what you're talking about. That said, Python itself is mostly a procedural language, with the functional tools really being bolted on[1]. When we're talking about Py3K, I think we're really talking about a redesign and rethink of pretty much the entire language -- with list and generator comprehensions, for procedural programming the need for map and lambda goes away. Reduce isn't directly replaced, of course, but a for-loop implementation (for procedural programming) is clearer, more powerful, more explicit, and possibly faster. That said, I very much like the idea of putting map and filter in a functional module. For applications like functional-style programming where map/etc are clearer, that keeps them in the library for efficient use, yet it leaves the native language with OO(g)WTDI [Only One (good) Way to Do It]. [1] -- lambda excepted. I think it's kind of cute, in a baby-mammal kind of way. -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Christopher Subich wrote: That said, Python itself is mostly a procedural language, with the functional tools really being bolted on[1]. [etc., snip] Yeah, that's pretty much what I said in the first place. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
John Roth wrote: Robert Kern [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] map and filter are being removed *because of* list comprehensions. Did you even read Guido's articles about this issue? Your understanding of why these changes are planned is incorrect; consequently your projection based on that understanding is not on firm footing. May I most respectfully point out that you've got it backwards. Part of the justification for list comprehensions was that they could be used to replace map and filter. The jihad against the functional constructs has been going on for a long time, and list comprehensions are only one piece of it. Many people believe that the functional constructs in Python exist to enhance Python's support of functional programming, but that's wrong. They exist to enhance support of procedural programming. In other words, the functional elements were added not because Python embraced functional programming, but because discreet use of functional code can make procedural programs simpler and more concise. Listcomps et al. cannot do everything map, lambda, filter, and reduce did. Listcomps are inferior for functional programming. But, you see, functional is not the point. Streamlining procedural programs is the point, and I'd say listcomps do that far better, and without all the baroque syntax (from the procedural point of view). Jihad? I'd say it's mostly just indifference to the functional programming cause. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
egbert wrote: On Sat, Jul 02, 2005 at 08:26:31PM -0700, Devan L wrote: Also, map is easily replaced. map(f1, sequence) == [f1(element) for element in sequence] How do you replace map(f1,sequence1, sequence2) especially if the sequences are of unequal length ? I didn't see it mentioned yet as a candidate for limbo, but the same question goes for: zip(sequence1,sequence2) OK, you guys are picking on what reduce cannot do. The first is [f1(*args) for args in itertools.izip(iter1, iter2)] How to _you_ use map to avoid making all the intermediate structures? I never saw anything about making zip go away. It is easy to explain. Now reduce maps to what I was taught to call foldl. How do you express foldr? How do you express: _accum = initial() for elem in iterable: _accum = func(elem, _accum, expr) ... If you want functional programming in python, you have at least three big problems: 1) Python has side effect like mad, so order of evaluation matters. I'd claim any useful language is like that (I/O to a printer is kind of hard to do out-of-order), but I'd get sliced to death by a bunch of bullies wielding Occam's razors. 2) Python's essential function call is not a single-argument function which might be a tuple, it is a multi-argument function which is not evaluated in the same way. The natural duality of a function taking pairs to a function taking an arg and returning a function taking an arg and returning a result breaks down in the face of keyword args, and functions that take an indeterminate number of arguments. Also, because of (1), there is a big difference between a function taking no args and its result. 3) Python doesn't have a full set of functional primitives. Fold-right is one example, K-combinator is another, Why pick on reduce as-is to keep? There is another slippery slope argument going up the slope adding functional primitives. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
On Sun, 03 Jul 2005 08:14:28 -0700, Scott David Daniels wrote: egbert wrote: On Sat, Jul 02, 2005 at 08:26:31PM -0700, Devan L wrote: Also, map is easily replaced. map(f1, sequence) == [f1(element) for element in sequence] How do you replace map(f1,sequence1, sequence2) especially if the sequences are of unequal length ? I didn't see it mentioned yet as a candidate for limbo, but the same question goes for: zip(sequence1,sequence2) OK, you guys are picking on what reduce cannot do. The first is [f1(*args) for args in itertools.izip(iter1, iter2)] And now we get messier and messier... Compare these two idioms: Map function f1 to each pair of items from seq1 and seq2. Build a list comprehension by calling function f1 with the unpacked list that you get from a list built by zipping seq1 and seq2 together in pairs. Good thing that removing reduce is supposed to make code easier to understand, right? How to _you_ use map to avoid making all the intermediate structures? I don't understand the question. Presumably the sequences already exist. That's not the point. I never saw anything about making zip go away. It is easy to explain. I don't find map any less clear than zip. Except for the arbitrary choice that zip truncates unequal sequences while map doesn't, zip is completely redundant: def my_zip(*seqs): return map(lambda *t: t, *seqs) Zip is just a special case of map. I find it disturbing that Guido is happy to fill Python with special case built-ins like sum, zip and (proposed) product while wanting to cut out more general purpose solutions. [snip] If you want functional programming in python, you have at least three big problems: 1) Python has side effect like mad, so order of evaluation matters. Not if you *just* use functional operations. Not that I would ever do that. The point isn't to turn Python into a purely functional language, but to give Python developers access to functional tools for when it is appropriate to use them. 2) Python's essential function call is not a single-argument function which might be a tuple, it is a multi-argument function which is not evaluated in the same way. And I'm sure that makes a difference to the functional programming purists. But not to me. 3) Python doesn't have a full set of functional primitives. Fold-right is one example, K-combinator is another, Why pick on reduce as-is to keep? There is another slippery slope argument going up the slope adding functional primitives. My car isn't amphibious, so I can't go everywhere with it. Should I throw it away just because I can't drive under water? No, of course not. Just because Python isn't a purely functional language doesn't mean that we should reject what functional idioms (like list comps, and zip, and reduce) it does have. Personally, I'd like to learn more about about fold-right and K-combinator, rather than dump reduce and map. Frankly, I find this entire discussion very surreal. Reduce etc *work*, right now. They have worked for years. If people don't like them, nobody is forcing them to use them. Python is being pushed into directions which are *far* harder to understand than map and reduce (currying, decorators, etc) and people don't complain about those. And yet something as simple and basic as map is supposed to give them trouble? These are the same people who clamoured for zip, which is just a special case of map? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Carl Banks wrote: Listcomps et al. cannot do everything map, lambda, filter, and reduce did. Listcomps are inferior for functional programming. But, you see, functional is not the point. Streamlining procedural programs is the point, and I'd say listcomps do that far better, and without all the baroque syntax (from the procedural point of view). I've heard this said a couple times now -- how can listcomps not completely replace map and filter? I'd think that: mapped = [f(i) for i in seq] filtered = [i for i in seq if f(i)] The only map case that doesn't cleanly reduce is for multiple sequences of different length -- map will extend to the longest one (padding the others with None), while zip (izip) truncates sequences at the shortest. This suggests an extension to (i)zip, possibly (i)lzip ['longest zip'] that does None padding in the same way that map does. Reduce can be rewritten easily (if an initial value is supplied) as a for loop: _accum = initial for j in seq: _accum=f(_accum,j) result = _accum (two lines if the result variable can also be used as the accumulator -- this would be undesirable of assigning to that can trigger, say, a property function call) Lambdas, I agree, can't be replaced easily, and they're the feature I'd probably be least happy to see go, even though I haven't used them very much. -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Scott David Daniels wrote: egbert wrote: How do you replace map(f1,sequence1, sequence2) especially if the sequences are of unequal length ? I didn't see it mentioned yet as a candidate for limbo, but the same question goes for: zip(sequence1,sequence2) OK, you guys are picking on what reduce cannot do. The first is [f1(*args) for args in itertools.izip(iter1, iter2)] How to _you_ use map to avoid making all the intermediate structures? Not quite -- zip an izip terminate at the shortest sequence, map extends the shortest with Nones. This is resolvable by addition of an lzip (and ilzip) function in Python 2.5 or something. And egbert's Chicken Littling with the suggestion that 'zip' will be removed. -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Steven D'Aprano wrote: Frankly, I find this entire discussion very surreal. Reduce etc *work*, right now. They have worked for years. If people don't like them, nobody is forcing them to use them. Python is being pushed into directions which are *far* harder to understand than map and reduce (currying, decorators, etc) and people don't complain about those. I find it surreal too, for a different reason. Python *works*, right now. It has worked for years. If people don't like the direction it's going, nobody is forcing them to upgrade to the new version (which is not imminent anyway). In the unlikely event that the latest and greatest Python in, what, five years or more?, is so alien that one can't handle it, one has the right to fork Python and maintain a tried-and-true-and-still-including-reduce- -filter-and-map version of it, or even just to stick with the most recent version which still has those features. And that's assuming it's not acceptable (for whatever bizarre reason I can't imagine) to use the inevitable third-party extension that will provide them anyway. I wonder if some of those who seem most concerned are actually more worried about losing the free support of a team of expert developers as those developers evolve their vision of the language, than about losing access to something as minor as reduce(). -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
On Sun, 03 Jul 2005 14:43:14 -0400, Peter Hansen [EMAIL PROTECTED] wrote: Steven D'Aprano wrote: Frankly, I find this entire discussion very surreal. Reduce etc *work*, right now. They have worked for years. If people don't like them, nobody is forcing them to use them. Python is being pushed into directions which are *far* harder to understand than map and reduce (currying, decorators, etc) and people don't complain about those. I find it surreal too, for a different reason. Python *works*, right now. It has worked for years. If people don't like the direction it's going, nobody is forcing them to upgrade to the new version (which is not imminent anyway). In the unlikely event that the latest and greatest Python in, what, five years or more?, is so alien that one can't handle it, one has the right to fork Python and maintain a tried-and-true-and-still-including-reduce- -filter-and-map version of it, or even just to stick with the most recent version which still has those features. And that's assuming it's not acceptable (for whatever bizarre reason I can't imagine) to use the inevitable third-party extension that will provide them anyway. I wonder if some of those who seem most concerned are actually more worried about losing the free support of a team of expert developers as those developers evolve their vision of the language, than about losing access to something as minor as reduce(). This is a specious line of reasoning. Here's why: Lots of people use Python, like Python, want to keep using Python. Moreover, they want Python to improve, rather than the reverse. Different people have different ideas about what improve means. Guido has his ideas, and since he's the BDFL, those are the ideas most likely to influence the direction of Python's development. However, Guido isn't the only person with ideas, nor are his ideas the only ones that should be allowed to influence the direction of Python's development. Guido himself wouldn't even be silly enough to take this position. He knows he is not the ultimate source of wisdom in the world on all matters programming related. So when people disagree with him, suggesting that they should leave the Python community is ridiculous. Just like Guido (and the overwhelming majority of the Python community - heck, maybe even all of it), these people are trying to improve the language. Leaving the community isn't going to improve the language. Continuing to operate actively within it just might. For my part, I lack the time and energy to participate in many of these discussions, but anyone who knows me knows I'm not silent because I see eye to eye with Guido on every issue :) I'm extremely greatful to the people who do give so much of their own time to try to further the Python language. Suggesting people can like it or lump it is a disservice to everyone. (Sorry to single you out Peter, I know you frequently contribute great content to these discussions too, and that there are plenty of other people who respond in the way you have in this message, but I had to pick /some/ post to reply to) Jp -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Steven D'Aprano wrote: On Sun, 03 Jul 2005 08:14:28 -0700, Scott David Daniels wrote: egbert wrote: On Sat, Jul 02, 2005 at 08:26:31PM -0700, Devan L wrote: Also, map is easily replaced. map(f1, sequence) == [f1(element) for element in sequence] How do you replace map(f1,sequence1, sequence2) especially if the sequences are of unequal length ? I didn't see it mentioned yet as a candidate for limbo, but the same question goes for: zip(sequence1,sequence2) OK, you guys are picking on what reduce cannot do. The first is [f1(*args) for args in itertools.izip(iter1, iter2)] And now we get messier and messier... Compare these two idioms: Map function f1 to each pair of items from seq1 and seq2. Build a list comprehension by calling function f1 with the unpacked list that you get from a list built by zipping seq1 and seq2 together in pairs. The shamelessness with which you inflated the verbosity of the latter is hilarious. Good thing that removing reduce is supposed to make code easier to understand, right? It was a bad example. I would say most people don't usually just call a function in the list comp, because, frankly, they don't have to. A realistic list comp would look something like this in a real program: [ x**2 + y**2 for (x,y) in izip(xlist,ylist) ] Now there's no longer much advantage in conciseness for the map version (seeing that you'd have to define a function to pass to map), and this is more readable. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Christopher Subich wrote: Carl Banks wrote: Listcomps et al. cannot do everything map, lambda, filter, and reduce did. Listcomps are inferior for functional programming. But, you see, functional is not the point. Streamlining procedural programs is the point, and I'd say listcomps do that far better, and without all the baroque syntax (from the procedural point of view). I've heard this said a couple times now -- how can listcomps not completely replace map and filter? If you're doing heavy functional programming, listcomps are tremendously unwieldy compared to map et al. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Christopher Subich wrote: Interesting; could you post an example of this? Whenever I try to think of that, I come up with unwieldly syntax for the functional case. In purely functional code the results of map/filter/etc would probably be directly used as arguments to other functions, which might make the calls longer than I'd consider pretty. This is especially true with lots of lambda-ing to declare temporary expressions. I personally think that map looks clearer than a list comprehension for a simple function call, e.g. map(str, sequence) vs. [str(x) for x in sequence] -- Erik Max Francis [EMAIL PROTECTED] http://www.alcyone.com/max/ San Jose, CA, USA 37 20 N 121 53 W AIM erikmaxfrancis In Heaven all the interesting people are missing. -- Friedrich Nietzsche -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Carl Banks wrote: The shamelessness with which you inflated the verbosity of the latter is hilarious. [snip] [ x**2 + y**2 for (x,y) in izip(xlist,ylist) ] Now there's no longer much advantage in conciseness for the map version (seeing that you'd have to define a function to pass to map), and this is more readable. and then, five minutes later in another post, wrote: If you're doing heavy functional programming, listcomps are tremendously unwieldy compared to map et al. Having a dollar each way I see :-) -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Robert Kern [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] map and filter are being removed *because of* list comprehensions. Did you even read Guido's articles about this issue? Your understanding of why these changes are planned is incorrect; consequently your projection based on that understanding is not on firm footing. May I most respectfully point out that you've got it backwards. Part of the justification for list comprehensions was that they could be used to replace map and filter. The jihad against the functional constructs has been going on for a long time, and list comprehensions are only one piece of it. John Roth -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
On Fri, 1 Jul 2005, Ivan Van Laningham wrote: Personally, I find that Lisp its derivatives put your head in a very weird place. Even weirder than PostScript/Forth/RPN, when you come right down to it. +1 QOTW! tom -- REMOVE AND DESTROY -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
John Roth wrote: Robert Kern [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] map and filter are being removed *because of* list comprehensions. Did you even read Guido's articles about this issue? Your understanding of why these changes are planned is incorrect; consequently your projection based on that understanding is not on firm footing. May I most respectfully point out that you've got it backwards. Part of the justification for list comprehensions was that they could be used to replace map and filter. That is essentially what I said. List comprehensions were made to replace map and filter. Now that they are here, Guido wants to remove map and filter to keep OOWTDI. My response was incomplete, not incorrect. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background unscientificmini-survey
Hi All-- Tom Anderson wrote: Comrades, I expect tons of disagreement in the feedback, all from ex-Lisp-or-Scheme folks. :-) I disagree strongly with Guido's proposals, and i am not an ex-Lisp, -Scheme or -any-other-functional-language programmer; my only other real language is Java. I wonder if i'm an outlier. So, if you're a pythonista who loves map and lambda, and disagrees with Guido, what's your background? Functional or not? I'm a pythonista who doesn't love them. In fact, even though I've done more than my fair share of lambda Tkinter programming using lambdas, I've never been happy with lambda. And I've spent months inside of Lisp/Emacs Lisp/Scheme, too (I have the world's second largest .emacs file [my friend Andy Glew has the largest], even though I can't use it on Windows;-). I find list comprehensions easier to understand than map, and small named functions or, better yet, class methods, *tons* easier to read/understand than lambda--there are too many restrictions you have to remember. Personally, I find that Lisp its derivatives put your head in a very weird place. Even weirder than PostScript/Forth/RPN, when you come right down to it. I won't miss them, but since I don't use them now, that doesn't mean a whole lot. Metta, Ivan -- Ivan Van Laningham God N Locomotive Works http://www.andi-holmes.com/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
