other python ideas

[Alex Martelli]

"Douglas Alan" <nessus at mit.edu> wrote in message
news:lc66geouo6.fsf at gaffa.mit.edu...
    [snip]
> Also, sometimes adding a language feature makes the language
> conceptually simpler, rather than more complicated.  For instance, if
> Python supported lexical closures, this would make it cleaner and more
> elegant.  It would remove the necessary voodoo of using unactualized
> optional arguments in nested functions.

This is (experimentally) in Python 2.1 (currently in the last beta
and due for release in a few days), and slated for non-experimental
definitive status for Python 2.2, so I think the "if ... supported", etc
mood should be changed to "when .. supports", etc -- it's not really
hypothetical, after all.  [The change is all about *nested lexical
_scoping_*, of course, NOT about 'closures' as all the wannabes
appear to believe -- not a line gets changed in the code handling
closures, they just automatically become nested-lexical-scoped
as everything does].  I doubt it will be such as an unalloyed blessing
as you seem to think (what experience, if any, do you have teaching
Python, and seeing what features give problems and what don't...?),
although it will surely make the computer-scientist-types happy.


> There are some features of Python that in my opinion should be *removed*
> for Python 3k.  Python has some excess flexibility that is only rarely
> useful but makes it difficult for a compiler to generate efficient
> code.  Should we want Python to achieve world domination, this is
> probably an important consideration.

Scheme, with comparable flexibility (and only a tad more complication),
has some compilers which generate _splendid_ code -- yet, alas, it
seems to be used mostly in teaching and researching CS; nor does
CLisp (vastly more complicated, but _rich_ with _excellent_
compilers) appear to be anywhere near the road to world dom.  So,
it's still to be seen whether what you call 'excess flexibility' is indeed
at all significant as a factor keeping the code-generation unoptimized
in Python, AND pretty doubtful that code-generation improvements
would be significant to Python's success as a language.

Why not give it a try?  There's a project called 'vyper' which aimed
to "remove excess flexibility" from Python and implement a much
better code generator for the new dialect/variant -- to top it off,
from a computer-scientist point of view, the system language for
its implementation is OCAML (nothing as crude and down to earth
as C or Java).  I think/suspect it's progressing pretty slowly, as we
have heard nothing about it for a while -- why not fire up google,
find all there is to know about vyper, and join the team and/or fork
the project and move it along on your own path?


Alex