Third Draft: Pep for Deprecating Builtins

[Steve Holden]

"James J. Besemer" <jb at cascade-sys.com> wrote in message
news:mailman.1020108174.25482.python-list at python.org...
>
> 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.
>
[ ... ]
> 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.
>
If you're talking about "from __future__ ...", these can only appear before
any other source lines, and so (bugs notwithstanding) they aren't as
difficult to detect as you believe. Remember that some imports from
__future__ modify how the compiler acts, so you can't just switch them on
and off at random.

> 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?
>
Honestly, there's has been a LOT of talk about this on python-dev, and the
developers are very aware of the pain such changes cause.

> 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.
>
It would also be a nicer place (for me :-) if everyone just did what I said.
Hasn't happened yet, though.

> 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.
>
But don't underestimate the cruft that has to be carried forward into new
implementations either. I appreciate what you're trying to say, but under
the hood there have been some radical changes in the last two releases. It's
amazing that such a small amount of code was broken as a result.

guido-feels-your-pain-ly y'rs  - steve
--

Steve Holden: http://www.holdenweb.com/ ; Python Web Programming:
http://pydish.holdenweb.com/pwp/