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
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.
>
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
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.
>
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
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! :-)
>
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.

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








More information about the Python-list mailing list