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

[Alex Martelli]

Georgy Pruss wrote:

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

It's not just that: it would break *well-coded* programs, programs that
are coded using the _BEST, MOST APPROPRIATE_ constructs, and not give any
really good alternative way to recode them.  It's not so much the 'else'
on _for_ -- removing _that_ would break a zillion good programs, but the
alternatives are almost decent, at least in most cases.  But the 'else' on
_try_?!?!  How would you code around _THAT_ lack?

One sign that somebody has moved from "Python newbie" to "good Python
programmer" is exactly the moment they realize why it's wrong to code:

    try:
        x = could_raise_an_exception(23)
        process(x)
    except Exception, err:
        deal_with_exception(err)
    proceed_here()

and why the one obvious way is, instead:

    try:
        x = could_raise_an_exception(23)
    except Exception, err:
        deal_with_exception(err)
    else:
        process(x)
    proceed_here()

What WOULD sound natural to you in order to express the crucial pattern:
1. first, try doing "this and that"
2. if "this and that" raises such an exception, do something
3. else (i.e. if it doesn't raise exceptions) do s/thing else instead
4. and then in either case proceed from here
...???

Trying to kludge it around with "status-flag" variables isn't very
satisfactory, of course -- it can only complicate things and add
error-prone needs for setting and resetting "status flags".  To me,
removing 'else' from 'try' and proposing to use status-flags instead
is about as sensible as making the same proposal regarding 'if' --
i.e., not very.

> My main suggestions were the first ones,
> dealing mainly with the lexer and the parser of Python.

Ah, I see -- you probably weakened the effectiveness of your post
by mixing in it things you cared little about and at the same time
were such as to ensure alarm among experienced Pythonistas.

Each of your proposals requires very detailed analysis to become a
PEP.  For example, consider one I do like a bit: the ability to insert
underscores in literal numbers.  If we enrich the lexer to allow
that, I would _also_ want at the very least a warning to be raised
if the underscores are not inserted at "regular" intervals -- this
would, I think, enhance the usefulness, by making the lexer able to
help diagnose at least _some_ typos in number literals.  However,
there seem to be arguments for at least two approaches: one, just
force the number of digits allowed between underscores to exactly
three -- probably the most common usage; or, two, allow any number
of digits between underscores as long as the usage is "consistent"
(within a single number?  or in a larger lexical unit, and, if so,
which one -- a module?).  In either case, the issue of number of
digits allowed before the first underscore and after the last one
should be tackled -- perhaps differently for sequences of digits
that come before a decimal point (or without any at all) or after
a decimal point.

Further, if we're able to _input_, say, 1_000_000 to indicate "a
million" to the lexer -- surely we'll want that same ability when
the same string is otherwise recovered (e.g. read from a file)
and then transformed into an integer by calling int(s).  Should
int(s) just accept underscores in string s, or be more selective?
Should underscores perhaps only be accepted in int(...) [and other
type constructors such as long(...), float(...), ...) if explicitly
enabled by an optional argument?

And what about the _output_ side of things?  Surely if 1_000_000
becomes an acceptable syntax for "one million" there should be a
simple way to make the number 1000000 _print out_ that way.  Should
that be through some optional argument to str() and/or repr()?  Or
a new function (and/or method), and where located?  How would we
get that effect with the %-formatting operator?

A PEP on this single change to the language would stand no chance
of acceptance -- it would probably, and quite correctly, just get
rejected outright by the PEP-editor, as clearly under-researched --
unless each and every one of these points (and probably more yet
that I haven't thought of -- all of the above is the result of just
a couple minutes' worth of thought, after all!) was identified and
clearly addressed, indicating what design choices were considered
and why they were accepted or rejected.  Considerations about how
such things are dealt with in other languages and why adopting their
solutions would be appropriate or inappropriate in Python would be
very helpful here, too.

And this one is probably the simplest out of all of your wishes,
right?  Plus, as I said, is one I might well like, so I'm definitely
not "looking for excuses" against it -- on the contrary, I'm trying to
pin down enough details so it stands a _chance_ (and it might, even
in Python 2.4, since changes that are useful and backwards-compatible
ARE under consideration for that, the next release).

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

Yep, I also recall PL/I (not very fondly...) and BAL (very fondly indeed,
though I admit it was on a /370 that I was using it -- I don't think there
were any /360's left by that time, at least not in IBM Research).


> No, no. I don't think that it's a good idea to fork Python. Again, I'm

Probably not -- forking rarely _is_ a good idea, except perhaps under
extreme provocation.  However, Python's conservatism might feel like
such (extreme provocation) to somebody who's truly gung-ho for change.

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

Yep -- as for me, I kept doing that continuously for the first (roughly)
three months of intense Python use, still a lot (just a bit less) over the
_next_ three months, and even though the frequency's been going down it's
mainly thanks to smart-editors which immediately show, typically by not
auto-formatting things as I expect, that I have _again_ forgotten.

However, I do like the colons there when I _read_ Python code, which, all
in all, I do far more often than writing it; so, the slight inconvenience
in writing is (for me, and by now) balanced out by the convenience in
reading.  You may want to investigate "smart editors" to see if the balance
can be made similarly acceptable to you.


Alex