Third Draft: Pep for Deprecating Builtins

[James J. Besemer]

Steve Holden wrote:

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

Good point.  Thanks for the clarification.

Nevertheless, having to look at the global context for basic things like how
divison works is really screwey and such changes should not be employed
gratuitiously.

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

I think there are two different things here: (a) bits of cruft carried forward
and (b) necessary radical new features.

The former is in the category of tempting, possibly irresistable but
inconsequential nits that in all likelihood more trouble than it's worth.  Plus
they tend to be highly controversial, like removing map from builtins.  We
should never use "from future" for mere "cruft".

The latter (with a few exceptions (like true division)) are highly desirable,
well thought out new features, e.g., lexical scoping, which correct a SERIOUS
shortcoming in the original language.  Although a radical change that cannot
help but break code, it's well worth the pain to move ahead.

FWIW

Regards

--jb

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