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

John Roth johnroth at ameritech.net
Tue Aug 6 14:39:19 CEST 2002


"Bryan Olson" <fakeaddress at nowhere.org> wrote in message
news:3D4EB939.2040207 at nowhere.org...
> François Pinard wrote:
>  > [Bryan Olson]
>
>  > 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.
>
> O.K. I wasn't trying to re-write the PEP, just point out the reasons.

Oh, go ahead. Rewrite the PEP. It seemes like it could stand some
improvement!
>
>

>
>  > 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?
>
> It more or-less-does.  Pure Python modules don't get their names from
> Python code, but from the file in which they're stored.  As for the
> assignment to a variable, I would rather use:
>
>      varname = import filename
>
> to make the semantics clear.

The trouble with this is that Python maintains an internal dictionary
of modules, by name. So

import filename

not only puts filename in the current module namespace,
but also puts it in the dictionary. That's not at all the same
thing as

foobar = import snafu

at least to the casual eye, and especially if the statement is
not at the module level. However, it could very well
be the same as

import snafu as foobar.



>  >>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.
>
> That strikes me as documenting well a badly designed feature.  Things
> that are the same should look the same.  Using the same assignment
> operator as with any other value suggests the function is assigned
like
> any other value.  Using a special construct suggests something else is
> going on.

As has been discussed, there is something else going on. The name
is bound to the module so it can be accessed by introspection. Never
having used this feature, I'm not certain of how essential it is.

>
>  >>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!
:-)
>
> Don't mean to insult anyone, but I have my doubts.  I've never seen a
> Python-based text on the level of Abelson and Sussman's /Structure and
> Interpretation of Computer Programs/ or Friedman, Wand and Haynes'
> /Essentials of Programming Languages/.

I think the point here is that of usability for teaching computer
science in
general, not for the ability to teach Python.
>
>
>  >> > 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).
>
> Who said adding list comprehensions was wrong?  The point is that
'need'
> is not really the issue.  I could just as easily say that recent
> additions to Perl alleviate the need for Python.  The language would
be
> better with a full lambda, that's all.

I don't think that list comprehensions have anything to do with the
matter.
Extending lambda has been discussed many times, and has never gotten
past the discussion stage because implementing def in expression format
is simply too much of a change to the language. Just to mention one
of the issues: how do you do a clean if/else/elif syntax in an
expression
format?

John Roth
>
>
> --Bryan
>





More information about the Python-list mailing list