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

[Georgy Pruss]

"Alex Martelli" <aleax at aleax.it> wrote in message news:K3Krb.446059$R32.14871630 at news2.tin.it...
| 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").

That particular item, 'else' for 'try' and 'for' has the lowest priority for me,
if I dare to say so. Of course I understand that it would break many many
existing programs. My main suggestions were the first ones, dealing mainly
with the lexer and the parser of Python.

I have rather little experience with Python, but very big programming
experience. I remember PL/I and IBM/360 assembler :) And I like Python a lot.

| 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.

I see.

| <...>
| 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.

No, no. I don't think that it's a good idea to fork Python. Again, I'm
quite happy with what it is now. I don't insist on introducing the switch
statement and conditional expression in 3.0. But I forget a colon for
each 'else' and I feel that I'm not the only one.

| E.g., you might center your new language's development on a
| drastically different principle from Python's (which is that Guido,
| <...>
|
|
| Alex
|

Thank you for the answer Alex.
Georgy