Comment on draft PEP for deprecating six builtins

[Lumberjack]

"Raymond Hettinger" <python at rcn.com> wrote:
> Abstract

Deleted. "Abstract" is right. Reality doesn't enter into it.

>     There are separate motivations for each function.  One motivation
>     in common is that the number of total built-ins should be as small
>     as possible to limit the amount of "core language" one needs to
>     know in order to read code that is not module specific.

Huh? The "core" language wouldn't be measurably shrunk by this proposal 
fella. Your rationale is built on air. Show us some genuine _advantage_ 
that is worth the huge _cost_ in time and effort caused by your ill-
considered proposal. How about you and other PEP writers take some 
responsibilities for your fantasies for once? You up to helping thousands 
rewrite their code? I thought not.

>     Creating a separate module
>     allows room for a large variety of functionals (e.g. fold, head,
>     tail, take, drop, etc.) to be introduced without cluttering the
>     built-in namespace. 

Run away! Run away! You know, you can _still_ create your precious 
functional style programming module _without_ removing or deprecating the 
existing so-called functionals. But no, you'd rather break code and make 
existing instructional material obsolete and require existing Python 
programmers to _unlearn_ some existing patterns. But it is for a good cause 
- if only you could articulate it!

>     Pow() and divmod() are more related to math module functions than
>     any of the built-in functions.  In general, they are rarely used. 
>     Because the ** operator is available, the pow() function is rarely
>     called directly.

Proof by assertion. Wonderful! Is the evidence hiding in the period at the 
end of your last sentence? Cause I didn't see it anywhere else.

>     Input() is easily replaced by eval(raw_input()).  It has few
>     legitimate uses and presents a security risk in most programs where
>     it is used. Though the risks are well documented, experience on
>     python-tutor and help at python.org indicates that new users
>     frequently use input() when raw_input() was intended and that they
>     are unaware of the embedded eval().

Why not just shoot the beggars who use the function? The would be in line 
with the contempt you seem to have for others.

> Key Issue
> 
>     All of these functions have been in-place since the beginning, are
>     used in mountains of code, and appear in every Python book.  The
>     situation would appear to be immovable.

Then why the hell are you proposing it? You think the world revolves around 
your notion of "rightness"?

> Implementation and Deprecation Timetable
> 
>     The module additions would go into Python 2.3.  All six functions
>     would be left intact and raise deprecation warnings in Python 2.3
>     and 2.4. The six functions would be removed in Python 2.5 (having
>     allowed two versions and a full year for code updates).

A FULL year! The mind boggles! Civilizations can grow, live, and die in 
that time! Maybe you should make it three weeks! Of course, a pregnancy 
lasts 9 months and girls begin menustruating around 12 years, and people 
typically aren't considered duly educated till their early 20's, still, we 
shouldn't let human time scales dictate how fast we can roll out new 
computer language changes!

I believe the organization you belong to has this chant:
REMEMBER: Change is progress! Progress is change! Either you are for 
progress or for congress! All right thinking embrace change! Evil people 
hate change!

> Copyright
> 
>     This document has been placed in the public domain.

Take it back! I want no part of it.