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

Steve Holden sholden at holdenweb.com
Mon Aug 5 15:11:51 CEST 2002

"François Pinard" <pinard at iro.umontreal.ca> wrote in message
news:mailman.1028549348.21388.python-list at python.org...
> [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
> >  > else, the rationale should stress, in very convincing ways, why
> >  > 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
> 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
> 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
But you need to remember that the name bound to the function in the def
statement is, in some small way, special:

>>> def myfunc(x):
...     pass
>>> myfunc
<function myfunc at 0x100fd438>
>>> a = myfunc
>>> myfunc = None
>>> a
<function myfunc at 0x100fd438>

> > 2) The current rules mislead people, away from an understanding of
> > 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.
Except that, as I pointed out above, the name bound in the "def" statement
remains as a property of the function

> > 4) Lack of a full lambda prevents Python from being a really good
> > 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! :-)
I agree that there is absolutely *no* need to have lambda at all, let alone
"full" lambda, to be a good teaching language.

> >  > 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).
It seems like John is suggesting we should remove "def" from the language.
That can't be right.

Steve Holden                                 http://www.holdenweb.com/
Python Web Programming                http://pydish.holdenweb.com/pwp/

More information about the Python-list mailing list