New statement proposal for Python

[Alex Martelli]

"Nick Perkins" <nperkins7 at home.com> wrote in message
news:GfeW6.237297$eK2.50503927 at news4.rdc1.on.home.com...
> ..nicely done, Alex!

Thanks!


> ..but what is your opinion as to whether this functionality belongs in the
> language itself?

Neutral.  I don't think it would do Python any irreparable harm if the
standard site.py included 6 more lines to install a suitable instance
in sys.module['const'], but it's hardly a key issue IMHO.

> Those coming from other languages are likely to expect to have constant
> values of some sort.

Those coming from other languages expect all sort of things which
their previous languages "offered" to them.  Implicit scoping in
methods (rather than explicit self.whatever references), magical
calling of superclasses' __init__/__del__ (if from C++ -- not if
from Java), ability to call functions without parenthesis (if from
Visual Basic up to 6 included -- removed in VB 7), implicit change
of strings to numbers and back (if from Perl or Visual Basic, not
if from C++ or Java), mandatory and/or optional declarations of
variables and/of their types, class methods (with very different
semantic expectations if they come from Smalltalk or rather from
C++ or Java), macros (again, very different expectations if from
C, or Scheme, or Common Lisp), "reference" parameters (implicitly,
if from Fortran or some versions of VB -- at least as an option,
if from C++ or other versions of VB or Pascal), private and/or
'friendly' and/or protected members (if from C++ or Java or Eiffel,
at least), a baseclass common to all objects (if from Java or
Smalltalk, not if from C++), unnamed codeblocks (if from Smalltalk
or Ruby), named break/continue (if from Java or Perl)...

Oh, and, last but not least -- braces and/or begin/end, OF COURSE!-)

I COULD go on writing for hours and hours, of course, just in
listing all the things that those coming from other languages
are "likely to expect".  If Python had 1/10th of such variously
"expected" features, it would be a bloated, unwieldly, unusable
monster.  Of course, every paladin of one such change resolutely
refuses to look at the overall picture -- *HIS* change (or, in
theory, "hers" -- but I have not witnessed female proponents of
such changes, yet:-) is the one that matters.  "Yeah, right".

Guido has proved for over a decade that he does an insanely
great job in triage of such risk-of-featuritis, so most sensible
people have long given up on the Sysiphean task of explaining
to the endless stream of change-proponents how and why their
desires can already be well met in Python, or how and why they
are best left unmet.

Those which CAN be well met (a large majority) often involve
some tiny device -- a few lines' worth of class or function --
and it is hopefully well known that any site can easily decide
to make such things "built-in" by tiny mods to site.py (or,
better, siteconfigure.py), while of course packages that are
to be distributed which rely on such devices can in turn
distribute the devices themselves as well.

Only an EXTREME minority of such features could or should be
mandated as built-in for ALL sites forever -- else, Python
would again bloat, albeit not strictly speaking on the
language-side of things.  Special syntax-sugar (which is
an extremely frequent request) for any such feature is, of
course, MOST unlikely to get into the language -- thanks be.

Any syntax sugar whatsoever for const.goo would be a total,
utter, unrelieved, unPythonic horror, IMHO.

Having 'const' bundled in the default site.py would be no
horror.  Probably not the wisest single thing to add out
of all the huge list above (which is only a little and very
partial list of typical desiderata stemming from other
languages), but not the least-wise one either.

One (IMHO) Python enhancement would be to give dictionaries
some finer-grained control on their degree of mutability.
The ability to selectively make SOME existing keys non
rebindable and/or non removable _would_ come in handy in
quite a few places ('constants' included), as would the
related ones of locking a dictionary against addition of
new keys.  Since ALMOST all Python namespaces are in fact
dictionaries (local-variables of functions being the
signal exception), such locking would give the basic
semantics for several desirable tricks.  But that's a
whole 'nother issue, would offer no new "pretty" syntax
sugar anyway, and thus would most likely be of no
interest whatsoever to most typical change-proponents.


> Your solution looks great, but still you have to type "const.foo" instead
of
> just "foo".

Right!  That's what makes it *Pythonic*.  No messing about
with the semantics of identifiers.

> How much run-time overhead does this involve?  I suppose only a tiny
amount,
> and perhaps no more than even a 'language-level' implementation would
have,
> but I think I would probably not use this in my most-inner loops.

If your innermost loops are in functions, copying whatever
values you're using in the depth of the loop to local
variables of your functions IS likely to offer you a
pretty good speedup.  This includes functions you are
calling, by the way, as well as methods you're calling, &c.

But -- don't optimize prematurely... it's a losing approach!


> I suppose one could always bind a local name to the value..
> width = const.width
> ..but then 'width' is no longer constant, and can be changed at will.

Local variable 'width' never was constant, so 'no longer' is
a strange word-choice (it seems to imply that once upon a
time it was?-).

But if you're talking of an inner-loop, you're talking of a
few lines of code, so where's the risk?


Alex