New statement proposal for Python

[Alex Martelli]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.992695645.13636.python-list at python.org...
    ...
> That leaves the only post-1.0 addition, "assert".  It took years to get
that
> in -- although it's hard now to remember exactly why.  The primary reason
> it's a keyword is so the compiler can eliminate it under -O.

Not sure I understand that motivation... the compiler under -O can
eliminate non-keyword stuff too:

D:\py21>python -O
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():
...     print 'before'
...     if __debug__:
...         print 'inside'
...     print 'after'
...
>>> import dis
>>> dis.dis(f)
          0 LOAD_CONST               1 ('before')
          3 PRINT_ITEM
          4 PRINT_NEWLINE
          5 LOAD_CONST               2 ('after')
          8 PRINT_ITEM
          9 PRINT_NEWLINE
         10 LOAD_CONST               0 (None)
         13 RETURN_VALUE
>>>

...the whole "if __debug__:" statement being 'eliminated', no?  I do
understand that identifiers with __  in front and back are 'sort of
reserved', but, not keywords, aren't they?  I'm *NOT* arguing against
assert, mind you -- one of my favourite statements -- just trying for
better understandings of the why's and wherefore's.


> Guido should have made "keyword" a keyword too.  Then we could have had a
> keyword statement at the top of each module, identifying all the post-1.0
> keywords your code wants to use <0.9 wink>.

That COULD be done by having the module assign a literal to
__keywords__ at the top -- the leading & trailing underscores
making it magic and 'reserved', no 'clean' code can get
broken (for some definition of 'clean').  Despite that missing
wink-fraction, this doesn't appear to be highly Pythonic though.

> "const frameworks" get invented routinely, but their inventors appear to
> drop them after the heat of argument fades.  Why bother?  A universal

In my case, mostly a (vain) hope of stifling a yet-one-more-round-of-
"enhancement"-demands.  Silly of me to hope, but...

> convention supplies all of maintainability, clarity, consistency, and a
> foundation for good programming habits too.  What it doesn't do is insist
> that you follow it against your will.  That's Python!
>
> Guido once said that protection mechanisms in Python are like bicycle
locks
> in Amsterdam:  they're advisory.

That's what a __setattr__ method in a class does inter alia -- it ADVISES
against not-meant-to-happen accidental bindings/rebindings (by raising
an exception) while still letting you access the __dict__ when you really
need to get around it.  A pure convention is weaker than an advisory
mechanism.  There is no advisory mechanism for "constants" (except as
attributes in a suitable object) -- JUST the convention.  That may be
a tad too weak in some cases (I'm neutral on that).  It sure discourages
some people from learning enough Python to see it doesn't matter.

The advisory __whatever mechanism, which supplemented the purely-
conventional _whatever one, did help to make a couple Python converts
in my experience already -- they'd walk away BUT, when they saw there
WAS a way to make stuff private-enough (C++'ists DO know that deep
down there's no real guarantee, just convention;-), they kept going for
long enough to see it's not a big issue either way.  I suspect similarly
weak-but-not-totally-inexistent mechanisms for other kinds of advisory
protection would have similarly positive effect.


> to *really* frustrate your errant coworkers.  If you can't trust
*yourself*
> to adhere to simple conventions, though, Python isn't your language.
>
> otoh-keep-using-it-and-you'll-change-so-that-it-is<wink>-ly y'rs  - tim

That's why it's worth luring people into Python with bait-and-switch
tactics IMHO.


Alex