Am I the only one who would love these extentions? - Python 3.0 proposals (long)

Alex Martelli aleax at aleax.it
Mon Nov 10 05:50:18 EST 2003


Georgy Pruss wrote:
   ...
> I would like to propose some extentions to the language, probably
> for the version 3.0. They are mainly lexical or syntactical and the
> language will stay compatible with 2.X (even although it was

Not at all -- these changes would break the vast majority of significant,
well-coded existing Python programs, for example by removing the 'else'
clause on 'try' for no other reason that it "sounds very unnatural" to you.
(I'm not sure how extensive your Python experience is, but this remark
suggests "not very").

3.0 will not guarantee 100% backwards compatibility (that is what will
make it a 3.0 rather than a 2.something), but the main way Guido will
use that extra degree of freedom is by removing some redundancies and
complications that have crept in the language and built-ins over the
years due to the need to keep compatible with past versions even while
better ways to perform many tasks were developed.  I believe it is
totally out of the question that something as crucial to good Python
coding as try/except/else will be removed.  I also strongly doubt the
changes will go in the direction of _introducing_ many "more than one
way to do it"'s, given that Guido's on record as advocating exactly the
reverse direction for 3.0 -- simplification, _removal_ of MTOWTDI's.

> declared somewhere that it's not the main concern in the Python
> community) but some of them are a bit more "radical." Yes, I know
> that some of the proposals were discussed here before, but I don't
> think it means that the language is frozen in its development

Of course not, but the direction of that development appears likely,
in most important ways, to go exactly the _other_ way round from
what you would want (introducing many more looping constructs, etc).

This suggests to me that, if you're truly keen on all items on your
wish list, you might want to consider _forking_ Python (or perhaps
some other language that is already closer than Python to many of
your wishes, such as Ruby).  Sure, a decision to fork is considered
very extreme in the open-source world, but then, so is your list of
60 or more items grouped under 16 headings.  If you can get some
substantial number of people agreeing to a majority of your desires,
and more importantly to your overall stance and philosophy on
language design, then starting your own language with Python as its
base might be more productive for y'all than wasting your efforts
lobbying for changes most of which are unlikely to ever be accepted.

E.g., you might center your new language's development on a
drastically different principle from Python's (which is that Guido,
the language architect with the consistent vision and a proven track
record of making good design trade-offs, gets absolute veto rights);
for example, "any change with 50% or more of votes that can in fact
be implemented gets in", or something like that.  I'm a pessimist and
my prediction is that such an effort would rapidly degenerate into an
inconsistent mess, but, hey, I might be wrong -- here's your chance
to prove that Eric Raymond's theorizations about cathedrals and
bazaars are well-founded, by making a much more bazaar-like and less
cathedral-like language-design environment than Python's.


Alex





More information about the Python-list mailing list