Third Draft: Pep for Deprecating Builtins

James J. Besemer jb at cascade-sys.com
Mon Apr 29 15:20:29 EDT 2002


These changes sound like a BIG improvement over the original draft PEP.

I pretty much agree with the changes, with a few exceptions noted below.

Regards

--jb

Raymond Hettinger wrote:

> >From the comments, I've learned:
>
> 5.  oct() is another candidate based on the rarity of usage

Candidate perhaps but some people still like Octal.

This still is a gratuitious change and thus should not be implemented.

If it ain't really broke, you shouldn't fix it.

> 7. the language needs some means of deprecating so that clutter
>     does accumulate.  that means needs to be well documented,
>     have a long, slow phase-in, and have a mechasism for
>     restoring old behavior if it is ever needed.

Without necessarily disagreeing, I would seriously QUESTION this point
and invite discussion on it

Making it easier to phase changes in and out makes things easier only
for the most active Python users.  Changes themselves are hard on the
user base generally.  Furthermore, having a language where things like
base functionality routinely changes significantly from release to
release seems a Bad Thing.

Picture the poor newbie sitting down with his O'Reilly book, having just
installed 2.3 or 2.4 and can't figure out why some of the examples no
longer work.  O'Reilly has how many thousands of these books in the
pipeline?  I'm sure they're not anxious to issue a revised edition.
Steve Holden barely had time to get get the 2.1 appendix in his book.
This is not helping ANYBODY.

I frankly think it's ALARMING that people are becomming comfortable with
the notion that you can't interpret the meaning of programs without (a)
being up to date on how things change from release to release and (b)
paying close attention to the declarations or (super ugh) command
switches that might override defaults.  This is a much greater burden
than simply learning any particular version of the language.  It's a
moving target.  Of course users don't have to upgrade to each new
release and generally only use one version at a time.  But in trying to
use other people's code you're likely to encounter anything from old to
new, so you have the problem whether you want it or not.  Unless you
hide in your hole and only use code you write yourself.

As it is, we can no longer look at a fragment of code containing a
division operator and know what it means without checking version and
import declarations (which may appear ANYWHERE in the source).  I
frankly find this to be BIZARRE.

The more we add to this confusion the worse service we do to the user
community at large.  Easily phasing features in and out is clearly
something that ONLY benefits the most sophisticated users, leaving
beginners and non-programmers in the dust.  Some of the seeming experts
on this list cannot keep up, so how does the non-programmer have a
chance?

I think the world would be a better place if the language experienced a
lot FEWER non-backwards compatible changes.   Absolutely none is the
norm in most languages and would be an ideal here.  Also users would be
better off if we had a lot fewer releases altogether.  One major release
per year seems a healthy goal, with debug-only releases in between.
Even then, changes should focus on backwards compatible enhancements or
new features that don't break old colde rather than trying to fine-tune
existing features, even some of the few arguably regrettable ones.
Simply write them off to Python's rich heritage.

So, I think one could argue just the opposite of #7 -- that we should
look into policies that make it HARDER to deprecate and phase out old
functionality.  I don't see that it ever hurts to leave it in but
there's ALWAYS some pain to take it out.  None of the old vestiges are
so awful that they require change.  So don't do it.

IMHO.

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com







More information about the Python-list mailing list