Draft Pep (was: Re: Let's Talk About Lambda Functions!)
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
> > 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
> > The real
> > question is about whether having or not, in Python, a "thing"
> > for each and every thing which is not initially bound though
> > For example, `import' binds a module to a variable. Should Python
> > 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
not only puts filename in the current module namespace,
but also puts it in the dictionary. That's not at all the same
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
> >>class procedures.
> > I see this as a documentation problem. This might be easily and
> > adequately solved by stressing the fact a bit more in the Python
> > 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
> 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
> >>language. [...]
> > This is an exaggerated repetition of the second point. If it was
> > 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
general, not for the ability to teach Python.
> >> > Also, recent additions in Python are said to significantly
> >> > most of the need for anonymous functions, so the rationale of
> >> > PEP might explain why these additions are still not satisfactory
> >> > 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
> > about "complex def". I presume that when features like list
> > was added, and if bloating `lambda' would have been a better
> > it would have been considered at the time. The PEP should probably
> > why the designers have been wrong at the time (which was not so
> Who said adding list comprehensions was wrong? The point is that
> is not really the issue. I could just as easily say that recent
> additions to Perl alleviate the need for Python. The language would
> better with a full lambda, that's all.
I don't think that list comprehensions have anything to do with the
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
More information about the Python-list