map/filter/reduce/lambda opinions and background unscientificmini-survey

[Tom Anderson]

Comrades,

During our current discussion of the fate of functional constructs in
python, someone brought up Guido's bull on the matter:

http://www.artima.com/weblogs/viewpost.jsp?thread=98196

He says he's going to dispose of map, filter, reduce and lambda. He's
going to give us product, any and all, though, which is nice of him.

What really struck me, though, is the last line of the abstract:

"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?

tom

 

[Ivan Van Laningham]

Hi All--

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

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Ivan Van Laningham]

[Tom Anderson]

[Guido]
"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.

Same here. `lambda' could go away. Yet `map' is sometimes useful...

And I've spent months inside of Lisp/Emacs Lisp/Scheme [...]

I worked on Lisp / Scheme / Emacs-Lisp for many dozens of years.
Moreover, a few times for unusual machines, I implemented Lisps.

(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;-).

You are a shameless lier! It just _cannot_ beat the size of mine, at
least not so long ago when I still was an Emacs user. And despite its
size, my .emacs worked on a lot of systems, Windows included.

Personally, I find that Lisp & its derivatives put your head in a very
weird place.

Lisp / Scheme are very OK! Usable for a wide range of applications,
including system' -- with the proper choices, they can be fairly speedy
as well. Yet, for ubiquitous and day-to-day work, Python is nicer!

 

[iK]

Seems like he wants python programmers to solve their problems all in the
same way. While that is great for corporate slaves it is terrible for the
creative programmer.
Python is quickly becoming the visual basic of the 21 century. If you want
to have fun while getting some work done you need to look elsewhere. It's a
shame...

 

[George Sakkis]

Seems like he wants python programmers to solve their problems all in the

same way. While that is great for corporate slaves it is terrible for the
creative programmer.
Python is quickly becoming the visual basic of the 21 century. If you want
to have fun while getting some work done you need to look elsewhere. It's a
shame...

What do we have here, a perl troll ? Perhaps you need to post elsewhere
"to have fun".

George

 

[mcherm]

So, if you're a pythonista who loves map and lambda, and disagrees with
Guido, what's your background? Functional or not?

I avoid map sometimes, because I find its syntax less readable
than list (and expression) comprehensions. But occasionally it
is the most readable way to do something, and I wouldn't want to lose
it.

Lambda serves a very specific purpose: declaring small, in-place
functions which are no bigger than a single expression. I do this often
enough that I DO want special syntax for it. But I'll admit that I
wish "lambda" were about 5 or 6 characters shorter and didn't have such
an obscure name.

I disagree (and I've mentioned it before) with Guido's plan to remove
these eventually. I'm perfectly satisfied with the alternate plan to
move the functions like map to a module (perhaps named "functional").
(That doesn't help with lambda, though since it requires syntactical
support.)

And my background is definitely NOT functional: I started with Basic,
then learned Pascal well, then _lots_ of other languages (including
Lisp) to an academic level. I've been using Java and Python heavily
now for about 8 or 9 years. I _DO_ however feel quite comfortable
using a functional approach *for certain problems*.

-- Michael Chermside

 

[Devan L]

None of them are really indispensible. Map and filter cab be replaced
with list comprehensions. reduce is redundant except when multiplying a
series; there's a sum function for a reason. Lambda looks cleaner in
some cases, but you don't gain any functionality.

What really struck me, though, is the last line of the abstract:

"I expect tons of disagreement in the feedback, all from
ex-Lisp-or-Scheme
folks. "

Guido wrote somewhere that the original map, filter, and reduce came
from a lisp hacker who missed them.

 

[Steven Bethard]

I avoid map sometimes, because I find its syntax less readable
than list (and expression) comprehensions. But occasionally it
is the most readable way to do something, and I wouldn't want to lose
it.

I tend to avoid map as much as possible. The only places I'm still
tempted to use map is in cases like:

' '.join(map(str, objects))

But I'm slowly moving towards:

' '.join(str(o) for o in objects)

because it's easier to fix when I realize later that I should have written:

' '.join('x%sy' % o for o in objects)


In general, I don't think I'll really miss any of map, filter, reduce,
etc. My background's a lot of Java and and a little bit of LISP and ML.
I was never a fan of LISP, but I did like ML a lot. However, for
Python, I definitely find list comprehensions and generator expressions
easier to read, especially when I have to read back through code I wrote
a long time ago.

STeVe

 

[Mike Meyer]

Seems like he wants python programmers to solve their problems all in the
same way. While that is great for corporate slaves it is terrible for the
creative programmer.

No, he wants Python to be Pythonic. TMTOWTDI is not Pythonic.

Python is quickly becoming the visual basic of the 21 century. If you want
to have fun while getting some work done you need to look elsewhere. It's a
shame...

If you'd rather spend your time figuring out which of multiple ways to
do things is the best for the job at hand than producing code, there's
a language that makes TMTOWTDI a way of life.

<mike

 

[Erik Max Francis]

So, if you're a pythonista who loves map and lambda, and disagrees with
Guido, what's your background? Functional or not?

I'm familiar with several function languages but haven't used them
extensively; I was primarily a C++ programmer before I found Python. I
definitely use lambda, map, filter, and reduce, and will miss them when
they're gone.

 

[Ron Adam]

So, if you're a pythonista who loves map and lambda, and disagrees with
Guido, what's your background? Functional or not?

I find map too limiting, so won't miss it. I'm +0 on removing lambda
only because I'm unsure that there's always a better alternative.

So what would be a good example of a lambda that couldn't be replaced?

Cheers,
Ron


BTW... I'm striving to be Pythonic. ;-)

 

[Chris Smith]

Devan> None of them are really indispensible. Map and filter cab
Devan> be replaced with list comprehensions. reduce is redundant
Devan> except when multiplying a series; there's a sum function
Devan> for a reason. Lambda looks cleaner in some cases, but you
Devan> don't gain any functionality.

Devan> What really struck me, though, is the last line of the
Devan> abstract:

Devan> "I expect tons of disagreement in the feedback, all from
Devan> ex-Lisp-or-Scheme folks. "

Devan> Guido wrote somewhere that the original map, filter, and
Devan> reduce came from a lisp hacker who missed them.

My question is, why not move them into, say, a "functional" library,
so that legacy code can be handled via an import, and those heads
preferring to think that way can be satisfied, and those little corner
cases not handled by the newer, sweller syntaxes can still be managed?
IOW, just ripping them out of the core and leaving everyone in the
lurch doesn't seem too pythonic to me.
Best,
Chris

 

[Terry Hancock]

I find map too limiting, so won't miss it. I'm +0 on removing lambda
only because I'm unsure that there's always a better alternative.

Seems like some new idioms would have to be coined, like:

def my_function(a1, a2):
def _(a,b): return a+b
call_a_lib_w_callback(callback=_)

doesn't seem too bad, and defeats the "wasting time thinking of names"
argument.

So what would be a good example of a lambda that couldn't be replaced?

I suspect the hardest would be building a list of functions. Something
like:

powers = [lambda a, i=i: a**i for i in range(10)]

which you might be able to make like this:

powers = []
for i in range(10):
def _(a,i=i): return a**i
powers.append(_)

which works and is understandable, but a bit less concise.

The main obstacle to the lambda style here is that def statements
are not expressions. I think that's been proposed as an alternative,
too -- make def return a value so you could say:

powers = [def _(a,i=i): return a**i for i in range(10)]

Personally, I think this is understandable, and given that lambda
is to be pulled, a nice substitute (I would say it is easier to read
than the current lambda syntax, and easier for a newbie to
understand).

But it would probably encourage some bad habits, such as:

myfunc = def _(a,b):
print a,b
return a+b

which looks too much like Javascript, to me, where there are
about three different common idioms for defining a
function (IIRC). :-/

 

[Sean McIlroy]

Tom Anderson wrote:

So, if you're a pythonista who loves map and lambda, and disagrees with
Guido, what's your background? Functional or not?

glad you asked. personally i don't know lisp (or scheme), but now i've
decided to learn it, because eventually it will no longer be possible
in python to pass functions as arguments or return them as values. the
education sig will have to change its motto to "computer programming
for every C-programmer". until then hangers-on like myself can use
home-grown substitutes for the functional constructs (examples below),
but in my opinion the best thing is to migrate as soon as possible. the
real programmers are squeezing us out. now is the time to abandon
python for an intelligent language (macros! real conditional evaluation
instead of the and/or kluge!)

def LISTCOMP(f,s,g):
reval = []
for x in s:
if g(x):
reval.append(f(x))
return reval

def LAMBDA(arguments,value):
symbols = arguments.split(',')
def reval(*args):
for i in range(len(args)):
locals()[symbols] = args
return eval(value)
return reval

def MAP(f,s):
return LISTCOMP(f,s,LAMBDA('x','True'))

def FILTER(f,s):
return type(s)(LISTCOMP(LAMBDA('x','x'),s,f))

def REDUCE(f,s,t):
if not s: return t
return f(s[0],REDUCE(f,s[1:],t))

 

[John Roth]

Comrades,

During our current discussion of the fate of functional constructs in
python, someone brought up Guido's bull on the matter:

http://www.artima.com/weblogs/viewpost.jsp?thread=98196

He says he's going to dispose of map, filter, reduce and lambda. He's
going to give us product, any and all, though, which is nice of him.

What really struck me, though, is the last line of the abstract:

"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?

As far as biases is concerned: my background is assembler.
I've never learned Lisp (although I did learn Forth at one time.)

I think I could note that originally there were five of the things,
including apply, which was cleanly replaced by the * and **
notation in function definitions and calls.

Map, filter and reduce are three things one can do with lists
(or in fact more general sequences).
List comprehensions cleanly replace filter. They don't
quite replace map, and they definitely don't replace reduce.
Claiming that sum etc. do the same job is the whimper of
someone who doesn't want to openly disagree with Guido.

Lambda is a horse of a quite different color. There are times
when an inline definition is the best thing one can have for
notational expressiveness. While lambda has a lot of
problems, Guido seems to be resisting replacing it with
something that can actually do the job.

Having to define an external function or class doesn't
always improve expressiveness. Sometimes it reduces
it. To quote Sean O'Lochlain: "Sometimes the best
symbol for a sharp knife is a sharp knife." [1]

John Roth

[1] In one of Randall Garrett's Lord Darcy stories.

 

[Peter Hansen]

personally i don't know lisp (or scheme), but now i've
decided to learn it, because eventually it will no longer be possible
in python to pass functions as arguments or return them as values. the
education sig will have to change its motto to "computer programming
for every C-programmer".

Huh? Where did that come from? Functions are objects in Python and
I've not heard the least discussion about this being changed, until now.

Sean, what gave you the impression this would change?

-Peter

 

[Paul McGuire]

I have never written a line of Lisp or Scheme, so it took me a while to
grok "lambda" as a synonym for "expression to be evaluated later". I
then thought it was similar to Smalltalk's functional closures, since
you can define local arguments at the beginning of the block, and then
write the body of the block using those args. But then I saw that it
was only a subset of that capability, since one may only implement an
expression in a lambda, not a full code block.

Even with those limitations, I've found lambda to be a nice compact
form for specifying callbacks. It is especially helpful in pyparsing,
where I define a mechanism for the programmer to specify a parse action
to be performed, which can modify the matched tokens. Here is one that
is very compact:

quotedString.setParseResults( lambda s,loc,toks: toks[0][1:-1] )

Parse actions take 3 arguments: the original string being parsed, the
location of the beginning of the match, and a ParseResults object
containing the matched tokens (ParseResults objects can act as a list,
dict, or object with attributes). The purpose of this parse action is
to remove the opening and closing quotation marks from the matched
quoted string. One of the things I especially like about this
simplicity of parse actions is that there is no need for checking
whether toks is an empty list, or if the first and last characters are
quotation marks before stripping them - quotedStrings call their parse
actions *only* with a single element list, and only with the first
element containing a string with opening and closing quotes. Still, in
anticipation of the demise of lambda, and because this function is
frequently needed, I've added it as a built-in helper function to
pyparsing, called removeQuotes. But lambda is very simple and
immediate for defining such simple transforms, and there is no need to
go track down where a named function definition may be found. (Yes, I
*could* stop in my tracks just prior to this statement and define this
one-line function, but then this interrupts the flow of my grammar
definition.)

It seems to me that lambda's built-in limitation of *only* supporting
expressions, rather than complete code blocks, has led to people
applying their boundless creativity to trying to cram conditional logic
into bewildering and failure-prone boolean expressions, and it reminds
me of some of the C macro coding that I had to sift through about 20
years ago.

Not coincidentally, I think the lambda limitation is the true origin of
may of the requests we read on c.l.py for the proper syntax for
Python's version of the ternary ?: operator as in "how do I write
(x>10? a : b) in Python", which is invariably followed by a post such
as, "don't bother with that, just do "(x>10 and a or b)", which is then
usually followed with, "but watch out in case a evaluates to False..."

So personally, I like lambdas even if I am not found of the keyword
"lambda". Maybe we could replace "lambda" with "@" or "$"?

-- Paul

 

[Sean McIlroy]

Peter Hansen wrote:

Sean, what gave you the impression this would change?

just inductive reasoning. i've been wrong before (like anyone who makes
that claim), and i'm a former python enthusiast, so my judgement must
be colored to some extent by bitterness. maybe they have solid reasons
for scrapping the functional constructs. but to me it seems like
they're eliminating them just because they offend the sensibilities of
C-programmers. (i mean those stereotypical C-programmers, baffled by
recursion and the like, who don't want to be reproached with the fact
of their mathematical illiteracy.) if that's the case then list
comprehensions and/or "first class functions" are likely to be the next
target. even if they're not, it's pretty clear that python is leaving
its multiparadigmatic origins behind. "do it our way," the pundits are
effectively saying, "or get out". for my part, i'm getting out.

 

[Erik Max Francis]

if that's the case then list
comprehensions and/or "first class functions" are likely to be the next
target.

Slippery slope arguments are logical fallacies, you know.

 

[Robert Kern]

My question is, why not move them into, say, a "functional" library,
so that legacy code can be handled via an import, and those heads
preferring to think that way can be satisfied, and those little corner
cases not handled by the newer, sweller syntaxes can still be managed?
IOW, just ripping them out of the core and leaving everyone in the
lurch doesn't seem too pythonic to me.

Python 3000 will be breaking more backwards compatibility than
map/reduce/filter. That legacy code won't work anyways.

I predict, though, that one of the first 3rd party modules to come out
for Python 3000 will be such a library.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter