New statement proposal for Python

Alex Martelli aleaxit at
Fri Jun 15 11:53:39 CEST 2001

"David LeBlanc" <whisper at oz.nospamnet> wrote in message
news:9gbsdv$8ft$9 at
> alias where (argument) substition is done! At least conceptually the body
> of a function replaces it at invocation time.)

Fortunately ***NOT***!!!  Such a horrible "conceptual"
choice for a function-execution model would put pay to
any chance of *RECURSION*.

> read so nicely to be able to say "if something is true" rather then "if
> something is not 0" (saves on typing too :-)).

Such "read so nicely" tests would of course not work as
expected (with or without alias).  The object None, for
example, evaluates as false, but if you test its identity
with 0, you will of course find they're not *identical*
(how COULD they be -- they're different in every respect,
the ONLY thing they have in common is evaluating as false!).

It seems to me that the LAST thing we need is encouraging
"read so nicely" forms that do NOT do what a naive newbie
might expect.  It is absolutely fundamental that the
newbie learns to write his/her logical tests as:
    if something:
    if not something:
and *NOT*
    if something is 1:
    if something is 0:
or any "aliases" of these flawed forms.

> Other suggestions to import large libraries or make modules instances are
> not things calculated to gladden the heart of a newbie who seeks
> simplicity,

The module-instance (the example I gave) would of course
be made by a NON-newbie, the newbie would just USE it.  Why would
"a newbie who seeks simplicity" consider:

    const.magic = 23

less simple than

    alias magic : 23

?!?!  The former uses exactly the same syntax as any other binding,
requiring the newbie to learn absolutely no new syntax.  The latter
requires the newbie to learn one more "simple keyword-statement", with
a syntax totally different from that of all OTHER simple keyword
statements.  It seems to me that your claim that all of the extra
conceptual and syntactical baggage FAVOURS simplicity, when common
sense suggests extra baggage REDUCES simplicity, is an extraordinary
claim, and thereby requires extraordinary proof.

> nor would the code enlargement (my aren't I diplomatic ;))
> win the approval of an experienced developer who doesn't want to search
> exteraneous lines when a bug pops up - which is statistically more likely

What "code enlargement" are you talking about?  Which "exteraneous" (?)
lines?  In a script using "module const" there may or may not be a
single line
    import const
for explicitness (the alternative is having it performed implicitly
at startup, e.g. by &c &c, placing const in the
__builtin__ module, of course).  That's up to the "experienced
developer" who decides constants are necessary at his/her site.

> with more lines of code, not to mention the antics needed to do something
> that should be as simple as possible (imho).

What "antics"?  If you want 'const' to be activated by default
in every Python installation (e.g. in, write a PEP
proposing just that.  You DO realize, of course, that no matter
what little chance such a PEP may have, it IS going to be at
least a thousand times more likely to be adopted than anything
that will introduce a new keyword and thereby break perfectly
working code -- that's something that can *possibly* happen
only for really momentous developments (such as the new proposed
"yield" keyword-statement for generators) which DESPERATELY NEED
a new statement (can't POSSIBLY work halfway-decently without).

> One can certainly argue that this is syntactical sugar. It does however
> serve a multitude of good purposes among which are: maintainability;
> clarity;  consistancy; correctness; good programming habbits; - a not
> inconsiderable set of advantages for a little sugar.

I fail to see ANY of these advantages when comparing your "alias"
with a "const" module installed by  How is
    alias magic : 23
more maintainable, clearer, more consistent, more correct, or
a better programming habit than
    const.magic = 23
?!?!  Please bring SOME kind of argument for such extraordinary
assertions... your bald statements are not "support" for them!

> Finally, this wouldn't break any code,

Puh-LEEZE.  *ANY* use of 'alias' in existing code would be
broken.  Let's not make such obviously-false assertions...


More information about the Python-list mailing list