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

[Bryan Olson]

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.


 >>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.

If you mean "we" who read comp.lang.python and discuss PEP's, that's not
the audience for whom the language should aim to be clear.  If you mean
most Python users and potential users, then no, it's not so well
understood.

 > 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 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.

"At any price" seems to suggest something is expensive here.


 >>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.


 >>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/.


 >> > 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.


--Bryan