[Python-Dev] Bare except clauses in PEP 348

[Ron Adam]

Raymond Hettinger wrote:
>>Deprecation means your code will still work I hope every book that
>>documents "except:" also adds "but don't use this except under very
>>special circumstances".
>>
>>I think you're overreacting (again), Raymond. 3.0 will be much more
>>successful if we can introduce many of its features into 2.x. Many of
>>those features are in fact improvements of the language even if they
>>break old code. We're trying to balance between breaking old code and
>>introducing new features; deprecation is the accepted way to do this.

> Fredrik, please speak up.  Someone should represent the users here.  I'm
> reached my limit on how much time I can devote to thinking out the
> implications of these proposals.  Someone else needs to "overreact".

How about a middle of the road (or there abouts) opinion from an average
user?  Just my 2 cents anyways.

I get the impression that just how much existing code will work or not
work in 3.0 is still fairly up in the air.  Python 3.0 still quite a
ways off from what I understand.

So to me.. depreciating anything at this time that's not going to be
removed *before* Python 3.0 is possibly jumping the gun a bit. (IMHO) It
definitely makes since to depreciate anything that will be removed prior
to Python 3.0.  And to also document anything that will be changed in
3.0. (but not depreciate yet)

If/when it is decided (maybe it already has) that a smooth transition
can be made between 2.x and 3.0 with a high degree of backwards
compatibility, then depreciating 2.x features that will be removed from
3.0 makes since at some point but maybe not in 2.5.

If it turns out that the amount of changes in 3.0 are such as to be a
"New but non backwards compatible version of Python" with a lot of
really great new features.  Then depreciating items in 2.x that will not
be removed from 2.x seems like it gives a since of false hope.  It might
be better to just document the differences (but not depreciate them) and
make a clean break.

Or to put it another way... having a lot of depreciated items in the
final 2.x version may give a message 2.x is flawed, yet it may not be
possible for many programs to move to 3.0 easily for some time if there
are a lot of large changes.

My opinion is... I would rather see the final version of 2.x not have
any depreciated items and efforts be made to make it the best and most
dependable 2.x version that will be around for a while.  And then have
Python 3.0 be a new beginning and an open book without the backwards
compatible chains holding it back.  That dosen't mean it won't be, I
think it's just too soon to tell to what degree.

At this time the efforts towards 3.0 seem to be towards those
improvements that may be included in some future version of 2.x which is
great.

Is it possible the big changes have yet to be considered for Python 3.0?


Cheers,
Ron