Draft Pep (was: Re: Let's Talk About Lambda Functions!)

[François Pinard]

[Bryan Olson]

> Contrary to popular belief, lambda did not add anoymous functions
> to Python.  Python had them even without lambda.

> def define_twice():
>      def _twice(x):
>          return x + x
>      return _twice

> print define_twice()(17)

> The above code passes 17 to a function which is not bound to any name.

Yes, Python functions are indeed first class objects, and this is very
convenient in a lot of circumstances.

>  > If the rationale is essentially reduced to the vague statement of a
>  > "continuous interest", it is a pretty weak rationale.  Before anything
>  > else, the rationale should stress, in very convincing ways, why anonymous
>  > functions should grow stronger in Python, instead of being faded out.

> I tried to do that in a previous response.  [...]

Granted, and thanks for your reply.  Yet, the PEP should be self contained,
by repeating and summarising all related arguments, without readers having
to later dig into c.l.py archives.  Ideally, people should not come in a
few years, read the PEP (at the time either accepted and rejected), and
get the uncomfortable feeling that something important has been forgotten,
and not taken into consideration.  That's why the PEP should itself list
all considerations, within the limits of reasonable, of course!

> 1) Python should have a procedure builder which does not assign the
> procedure to a name, because procedure in Python are first-class values
> and do not have intrinsic names.

The `def' name is not intrinsic.  We all know it is a mere binding.  The real
question is about whether having or not, in Python, a "thing" builder
for each and every thing which is not initially bound though assignment.
For example, `import' binds a module to a variable.  Should Python have
an anonymous module constructor as well?  The same rational would apply...
There is a compromise between purity and practicality, here, and the feel
we have of Python tells us that the language is not for purity at any price.

> 2) The current rules mislead people, away from an understanding of first-
> class procedures.

I see this as a documentation problem.  This might be easily and more
adequately solved by stressing the fact a bit more in the Python tutorial
or elsewhere, say, than by changing the Python language itself.

> 3) The variables to which a procedure is assigned has nothing to do with
> the value that is the procedure.  [...]

This is a mere repetition of the first point.

> 4) Lack of a full lambda prevents Python from being a really good teaching
> language.  [...]

This is an exaggerated repetition of the second point.  If it was really
the case, I would be much tempted to doubt of the teachers, here! :-)

>  > Also, recent additions in Python are said to significantly alleviate
>  > most of the need for anonymous functions, so the rationale of this
>  > PEP might explain why these additions are still not satisfactory on
>  > that respect.

> A full lambda would alleviate the need for the more complex def.

I was thinking about list comprehension, I fear I am missing the point
about "complex def".  I presume that when features like list comprehension
was added, and if bloating `lambda' would have been a better solution,
it would have been considered at the time.  The PEP should probably state
why the designers have been wrong at the time (which was not so long ago).

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard