Comment on Draft Pep ver 4 -- Psuedo Deprecations of Builtins

[Raymond Hettinger]

Reading all of the posts on the deprecation pep shows that there is a
tension between ability to remove cruft versus breakage of old programs.
My idea for getting the best of both is psuedo-deprecation.

Let's take anything that shouldn't be there anymore (read as anything that
wouldn't be put in again if we were doing this from scratch) in a separate
section of the library reference called Obsolete Constructs.  We'll pull it
out of the main body of the docs and the tutorial; remove uses of it from
the Python library; and ask authors not to even mention the
psuedo-deprecates
(except in a separate section devoted to being able to read old code).

That way, we can publish a short, clean list of built-ins; create new
modules for functionals and iterttools; on go on merrily as if the language
had been truly cleaned.  Everyone can start using the language, not as Guido
had intended, but as he would intend if he had it to do over again.

I no longer think map(), filter(), and reduce() should even be
psuedo-deprecated,
but apply(), oct() and hex() are prime candidates.  The input() function
should
still be considered for genuine deprecation and deletion, but that reflects
my
view of input() as a bug.

We can add iterzip() and iterrange() to the builtins; psuedo-deprecate zip()
and range(); and live in a world with more uniform interfaces and less
unnecessary memory consumption.

Alex Martelli pointed out that this was the original concept of deprecation,
"it's there but we're sorry it is".

Neal Norwitz has already started building out PyChecker to issue warnings
for deprecated constructs.

Alex also pointed out that this form of "moral 'suasion" was tried with <>
vs !=.  Still, we have not tried isolating redundant, obsolete, or rarely
used functions in a separate, back-of-the-book section.

I think there is a clear advantage for creating a strong, central core of
what you need to know and de-emphasizing what was part of the past.

Though all the functions would still be in a dir() listing of __builtins__,
there is a powerful intellectual advantage to mentally whittling down
the list of tools to a well integrated, orthogonal, best-of-class set.

The quality of programs will improve, newbies will learn faster, the
language can advance, AND old programs will run fine.

'nuff said,


Raymond Hettinger