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

[Dan Bishop]

Claiming that sum etc. do the same job is the whimper of
someone who doesn't want to openly disagree with Guido.

Could you give an example where sum cannot do the job(besides the
previously mentioned product situation?

Here's a couple of examples from my own code:

# from a Banzhaf Power Index calculator
# adds things that aren't numbers
return reduce(operator.add,
(VoteDistributionTable({0: 1, v: 1}) for v in electoral_votes))

# from a custom numeric class
# converts a tuple of digits into a number
mantissa = sign * reduce(lambda a, b: 10 * a + b, mantissa)

Also, map is easily replaced.
map(f1, sequence) == [f1(element) for element in sequence]

There's also the issue of having to rewrite old code.

 

[Robert Kern]

There's also the issue of having to rewrite old code.

It's Python 3000. You will have to rewrite old code regardless if reduce
stays.

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

 

[Ron Adam]

These three I might prefer to keep.




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

 

[Ron Adam]

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

 

[Steven D'Aprano]

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.

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.

 

[Ron Adam]

It's Python 3000. You will have to rewrite old code regardless if reduce
stays.

And from what I understand Python 2.x will still be maintained and
supported. It will probably be more reliable than Python 3000 for a
version or two as well.

It's going to take time for all the batteries included to catch up, so
it won't be like we have to all of a sudden rewrite all the old Python
programs over night. We'll probably have a couple of years to do that
to our own programs if we decide it's worth while. And if not, Python
2.x will still work.

 

[Terry Hancock]

Really? I thought it was an abbreviation for "definition". As in,
"definition of MyFunc is..."

Does it matter? But no, "define" is correct, because the def
keyword is active. It is *not* a declaration of a function but
a command to define one then and there.

How about tuple?

It's a generalization rather than a specialization:

double (or couple)
triple
quadruple
quintuple
sextuple
septuple
octuple
nontuple
....

Maybe a wee bit less obvious, but still understandable.

Besides, the existence of another poor choice of words wouldn't
make the first one any better, would it?

If you are arguing that "lambda" is the "right and proper"
word for this operator that Python should use, I still will
have to disagree.

OTOH, if you just want the functionality of lambda to remain,
I must say I agree. It's a useful construct.

But it *is* poorly named. It really stands out as the least
intuitive keyword in the language, IMHO.

 

[Erik Max Francis]

It's a generalization rather than a specialization:

double (or couple)
triple
quadruple
quintuple
sextuple
septuple
octuple
nontuple
...

Maybe a wee bit less obvious, but still understandable.

The general form is explicitly called an "n-tuple" or "tuple" in
mathematics.

 

[Terry Hancock]

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.

With list comprehensions and generators becoming so integral, I'm
not sure about "unpythonic". And a syntax just occured to me --
what about this:

[y*x for x,y]

?

(that is:

[<expression> for <argument list>]

It's just like the beginning of a list comprehension or generator, but
without the iterator. That implies that one must be given, and
the result is therefore a callable object.

Wouldn't do anything more or less than present day "lambda", but
gets rid of the weird keyword, and integrates nicely with list comps
and generators. It's currently a syntax error, and it requires no
special delimiter -- it's really just an extension of list comp syntax.

 

[Steven D'Aprano]

I said I'd drop the discussion about lambda, but this
isn't really the same discussion even if it is part of
the same thread. That's my excuse, and I'm sticking to it.

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.

With list comprehensions and generators becoming so integral, I'm
not sure about "unpythonic". And a syntax just occured to me --
what about this:

[y*x for x,y]

?

(that is:

[<expression> for <argument list>]

It's just like the beginning of a list comprehension or generator, but
without the iterator. That implies that one must be given, and
the result is therefore a callable object.

That is a very long chain of implication:

"It looks like a list comprehension... but there is no
iterator... so we have to supply an iterator... so it
takes an argument... so it is a callable object... oh
and by the way, it can take any arguments, not just
iterators."

It is also far too easy to make a mistake, eg to write
something like newlist = [y*x for x,y] when you
actually wanted the list comp [y*x for x,y in L].

This would create an anonymous function where you
expected to create a list. It is hard to think of a
usage case where you didn't discover the error
reasonably soon, but it would be better for leaving the
iterator out of a list comp to remain a syntax error,
rather than produce an unexpected, but legal, object.

Besides, I think Guido should be very cautious about
introducing new features that use punctuation, instead
of keywords. We don't want to become perl do we?

 

[Antoon Pardon]

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

If Guido should change his mind on this, then it will be pythonic.
I don't think a concept that has so little meaning has any real
value.

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.

There are always many ways to do things, and depending on circumstances
the best way to do something may differ every time.

So if python no longer allows multiple ways to do things, it won't help
the programmer. The programmer will now face the question if python
is still the right language to do the job.

 

[Antoon Pardon]

The existence of list comprehensions are the reason that these
functions are going away, so they aren't likely to be next. It's all
part of "There should be one-- and preferably only one --obvious way
to do it."

IMO people concentrate too much on the "and preferably only one" part
of this.

If you really want at least one obvious way to do things then,
there also will be a lot of things that have more than one
obvious way. Trying to eliminate all those mulitiple obvious ways,
which seems to be one of the goals here, will result in removing
the one obvious way for doing other things.

 

[=?ISO-8859-1?Q?Daniel_Sch=FCle?=]

Full Acknowledge

 

[George Sakkis]

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.

These three I might prefer to keep.


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

 

[steve.morin]

map, filter, reduce and lambda
Lisp constructs, bring flexibility to the language and is why I started
programming in python to begin with. Removing these constructs will be
a shame and one step closer to the death of some of the basic features
that make python great.

 

[Tom Anderson]

On Tue, 05 Jul 2005 09:46:41 -0500, Terry Hancock wrote: [snip]

Def would be short for ... defend? defile? defer? defame? default? deflect?

There's always *something* to learn. Why def instead of define? Because
"easy to write" beats "instantly obvious to a beginner", if the word is
used all the time and is easy to memorize.

Still it's hard to explain why four specific python keywords - def,
del, exec and elif - were chosen to be abbreviated, while all the rest
are full words (http://docs.python.org/ref/keywords.html). "Ease of
typing" is a joke for an excuse;

For exec and probably del, yes, but def and elif are two of the most
frequently used keywords in the language, so i think it's reasonable to
keep them short.

So, who would object the full-word versions for python 3K ?

def -> define

I'd keep this short - it's one of the most commonly-used keywords. It's
particularly commonly used if you break your programs down into lots of
little functions; since this is, IMHO, something we want to encourage
people to do, we should strive to minimise boilerplate.

del -> delete

How about just getting rid of del? Removal from collections could be done
with a method call, and i'm not convinced that deleting variables is
something we really need to be able to do (most other languages manage
without it).

exec -> execute

This should be a function somewhere, maybe a builtin, maybe not - it
absolutely should not be a keyword. What that function should be called, i
don't know!

elif -> else if

I'm not sure about splitting it into two words; there's currently a very
simple relationship between flow control keywords, meanings, and blocks of
code, which would be broken if we moved to using "else if". I don't know
that this relationship is actually important, though.

tom

 

[Tom Anderson]

With list comprehensions and generators becoming so integral, I'm
not sure about "unpythonic".

I'm going to resist the temptation to argue that list comps are themselves
unpythonic .

Hang on, where's the punctuation in either of those? They *are* done with
keywords! A generator is just a function with "yield" instead of "return",
list comprehensions are just list literals where the explicit sequence of
items is replaced with code producing them, using the keywords "for", "in"
and "if", and a generator expression is a list comp *without any
punctuation!*

And a syntax just occured to me -- what about this:

[y*x for x,y]

?

Terrible. Square brackets mean a list, and a lambda is not anything like a
list.

I see where you're coming from, though; a lambda is a lot like the first
half of a list comp that's broken off and is roaming free. I can't think
of a good syntax for it, though.

tom

 

[Peter Hansen]

How about just getting rid of del? Removal from collections could be
done with a method call, and i'm not convinced that deleting variables
is something we really need to be able to do (most other languages
manage without it).

Arguing the case for del: how would I, in doing automated testing,
ensure that I've returned everything to a "clean" starting point in all
cases if I can't delete variables? Sometimes a global is the simplest
way to do something... how do I delete a global if not with "del"?

-Peter

 

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

[Tom Anderson]

How about just getting rid of del? [...] i'm not convinced that
deleting variables is something we really need to be able to do

While surely not in every program, I still use `del' often. Compare:

x = None
del x

when the goal is to cut the reference being held in x. Both statements
do it, yet the intent is expressed more legibly by the second.

(most other languages manage without it).

Hardly an excuse against some good ideas Python has on its own!

 

[Daniel Dittmar]

Arguing the case for del: how would I, in doing automated testing,
ensure that I've returned everything to a "clean" starting point in all
cases if I can't delete variables? Sometimes a global is the simplest
way to do something... how do I delete a global if not with "del"?

globals ().__delitem__ (varname)

except that the method would probably be called delete.

Daniel