Ideas for Python 3

[David MacQuigg]

On Wed, 05 May 2004 08:47:05 -0700, Josiah Carlson <jcarlson at uci.edu>
wrote:

>> The problem with this suggestion ( and many other similar uses of
>> existing functions ) is that it relies on a regular mathematical
>> sequence.  Think of a more general case, something like:
>> 
>> L = [:x:x**2, :x:x+4, :x:x/5, :x:2-x, :x:x*7 ]
>
>Ick.

Could you be more specific? :>)

>> Q1) Is it worth having a "lambda" syntax like this, or should we just
>> deprecate lambda functions entirely and use:
>> 
>> def f1(x): return x**2
>> def f2(x): return x+4
>> def f3(x): return x/5
>> def f4(x): return 2-x
>> def f5(x): return x*7
>> L = [ f1, f2, f3, f4, f5 ]

You seem to be suggesting that the current syntax is preferable.  Is
this really what you would prefer:

L = [(lambda x:x**2), (lambda x:x+4), (lambda x:x/5),
  (lambda x:2-x), (lambda x:x*7)]

>Don't deprecate lambda.  I know Guido is hot to do so, and believes it a 
>mistake to have in the first place, but is it really hurting anyone? 
>Sure, those who don't know how to use them, but the barrier for entry is 
>quite low.

The barrier *should* be low, but it isn't.  In Learning Python, 2nd
ed., there is a 5-page section under "Advanced Topics" devoted to
lambdas.  Some experts like the association with lambda calculus, even
though that doesn't help beginners.  In fact, it only serves to make
lambdas seem even more mysterious.  The benefit of lambdas *could* be
provided in a simple, self-explanatory syntax that requires zero pages
in a textbook and has none of the mystique that turns off beginners.

Lamdas add an unnecessary keyword and unnecessary burdens to the
syntax of the language.  The benefit is very small -- being able to
cram a function definition in a tight space.  Due to the mystique of
lambdas, it took me a while to realize that was their only benefit.

>> Q2) Will it help new users to have the "lambda" syntax be as close as
>> possible to a normal function definition?  i.e.
>> 
>> f :(x): return x**2  # a simple function
>> :x:x**2              # equivalent lambda expression
>> 
>> -- or --
>> 
>> f = def(x): return x**2
>> def x:x**2
>
>Ick on the four options just given.

The parentheses are optional when we have colons around the arguments.
Leaving them out is my preference, but I would be just as happy with

L = [:(x):x**2, :(x):x+4, :(x):x/5, :(x):2-x, :(x):x*7 ]

This would more strongly highlight the argument x, and still have a
form that parallels the standard function definition.

How about this:

f(x): return x**2
(x):x**2

Neat and clean, but I don't know if there would be parser problems
with the short form.  Unlike the long form, which can only occur at
the beginning of a line, the short form might occur in a dictionary
item, where the colon could lead to ambiguity.  Maybe we could say
lambdas in dictionaries must be enclosed in parentheses, or maybe just
not allow them at all where they might cause ambiguity.

>> I am especially interested in feedback from users who have recently
>> learned Python.  I suspect that many experienced users will have long
>> forgotten any difficulties they had while learning.
>
>Lerning lambda expressions are trivial when you have experience with 
>derivatives of LISP.  While I generally don't like to point users off to 
>go RTFM, in this case, 5 minutes of manual reading (without LISP 
>experience) will go a long way toward understanding lambda expressions.

My users ( EE students and professional design engineers ) have no
experience with LISP.  I agree, 5 minutes should be enough to explain
lambdas properly, but unfortunately, they are not explained properly
in the texts I have seen.

In my humble opinion, GvR should have ignored the experts who told him
lambdas were great, and just applied some simple common sense to find
a better solution.

-- Dave