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

[John Roth]

"Bryan Olson" <fakeaddress at nowhere.org> wrote in message
news:3D50BE19.20006 at nowhere.org...
> John Roth wrote:
>  > "Bryan Olson" wrote:
> [...]
>  >>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
>
> I don't see that.  What the import does is the internal stuff, and
> it returns a module.  That value, the module, gets stored in foobar,
> just as any other type of value gets assigned to a variable.
>
> [...]
>  >>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.
>
> That something else is irrelevent to the assignment of a value to a
> variable.  Do the something else in the special construct.  Do the
> assignment with the assignment operator.

Unfortunately, the "something else" requires having the name
within the def construct, which makes the assignment irrelevant.
The entire point of having the name bound to the function is for
introspection, source inspectors and similar uses, where you don't
want to have to have the coder do something special to enable it.

On thinking about this, I would like to see the line number of
the definition included; that would not only be more useful for
source inspectors, it would work transparently for lambda and
anonymous functions.

> [...]
>
>  > 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?
>
> That seems like a silly issue.  Either don't require lambda to operate
> only on expressions, as in, for example, Perl, or make the construct
an
> expression, as in, for example, various Lisps.

The first thing part of your comment is exactly what the proposal is
about.

One of the things I meant to imply is that all of the suggestions for
expression syntax
to date have foundered on the BDFL's (IMHO completely justified)
opposition.
I appreciate Python having clean, easily understood syntax (at least in
most places.) Sure, it's possible to define conditional expressions in
a number of ways, but I've never found a novice who could read them
easily. The same goes for embedded looping constructs, embedded
assignments,
embedded try blocks, and so forth. In fact, I've never seen a suggestion
for an expression
syntax for embedded try blocks, and embedded assignments have also
been shot down before.

In other words, trying to extend the expression syntax so lambda() can
define unrestricted functions is simply not Pythonic.

John Roth
>
>
> --Bryan
>