New statement proposal for Python

[Alex Martelli]

"Rainer Deyke" <root at rainerdeyke.com> wrote in message
news:JjgW6.284889$oc7.18565826 at news2.rdc2.tx.home.com...
    ...
> The following two statements are basically identical:
>
>   def f(x): return x
>   f = lambda x: x

They're close, with one obvious difference:

D:\py21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
Alternative ReadLine 1.4 -- Copyright 2001, Chris Gonnerman
>>> def f(x): return x
...
>>> f.__name__
'f'
>>> f = lambda x: x
>>> f.__name__
'<lambda>'
>>>

> I consider this a wart in the language.  Binding a function to a name is
> logically and physically the same operation as binding any other value to
a
> name; it should therefore use the same syntax.

You consider it a wart that more than one statement can bind
variables?  It's not just assignment and def -- class, import
and from behave the same way.  Notice one pattern: all kinds
of non-assignment binding-statements deal with objects whose
*NAMES* are significant *BOTH* in deciding the variable-name
to bind *AND* to locating or initializing the object that is
being bound.  The f.__name__ issue above is not a "it just
so happens".  It's similar to, say:
    import mynicemodule
vs
    mynicemodule = __import__('mynicemodule')

Thanks to import, def, and class, I do not need to type a LOT
of names twice, in the _extremely_ common case in which I do
want the variablename being bound to be the same as the name
of the object that is being bound (which is normally also the
object that is contextually being *created*, although the
semantics of sys.modules make creation a once-only occurrence
for module-objects specifically).

If _only_ assignment could ever possibly bind a variable, we
would need *expressions* (similar to today's __import__, but
syntactically much more complicated, since needing to hold
arbitrary amounts of code) that would also require us to type
each name twice -- or they would have to use black magic to
learn the name they're being bound to.

Moreover, we'd then have to deal with that precious built-in
function, setattr.  Binding a value to a named attribute is
logically and physically the same operation as binding that
value to that same named attribute (since it's EXACTLY the
same operation...); by your logic, "it should therefore use
the same syntax".  So how comes:
    fee.fie = foo.fum
and
    setattr(fee, 'fie', foo.fum)
and
    fee.fie = getattr(foo, 'fum')
and
    setattr(fee, 'fie', getattr(foo, 'fum'))
use four widely divergent syntax forms for the same op?-)
(operator.setitem has obvious similarities, too).

The answer, from my POV, is that names are reasonably-serious
matters.  In the case of attribute-reference-syntax versus
setattr/getattr, the reason for the difference is  that the
attribute reference is the obviously right way to do it for
an attribute name that is an overt constant, the built-in
function is just as obviously right when the attribute name
is anything *BUT* an overt constant (in identifier-syntax).
In the case of import, the specific advantage of the statement
is avoiding having to type the same name twice in 99.44% of
cases.  In the case of def and class, I have that same
advantage, plus, no need for any syntax which lets an
expression contain and coordinate statements.

Practicality beats purity, and this set of language design
choices strikes me as something that Python got just right.
A pretty deep, widespread, and precious "something", too.


Alex