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

[James J. Besemer]

Raymond Hettinger wrote:

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

I also think there is tension about the definition of "cruft" in and of itself.
Some people have strong view about what should stay or go but at the end of the
day it's all opinions.  I have not seen objective rational for most of the
proposed decisions (thus far in my short tenure here).

> My idea for getting the best of both is psuedo-deprecation.

This seems much more cautious and appropriate.  If there is some Liberal
editorial bias against using certain operators or in prefering some styles over
others, then that doc writer can start by changing his copies of introductory
documentation.

Old code, people who already mastered the old functions and people who for
whatever reason happen to prefer an unauthorized programming style can continue
without disruption.

Still, it seems to me to be a fairly pointless exercise.

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

Apply() and input() make some sense to me but what's so awful about oct() and
hex()?  From the narrow perspective of formatting integers, they fit mentally
quite nicely with str(), even though I realize that str() is part of some
greater, more general mechanism.  They're convenient, arguably simpler and
clearer than e.g., ( "%x" % n ).  Even though they're redundant, I don't see the
harm in simply leaving the poor babies alone.

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

And all you ultimately need to do to deprecate something is to SAY it's
deprecated.  It can stay deprecated forever, you don't ever actually have to
remove it, or even remand it to a seperate section of the doc.

Of course, that begs the bigger issue about what items, if any, should be
deprecated in the first place.  You seem particularly anxious to prune when I
fail to see the advantage.  If you were designing the language from scratch, it
would be a completely different matter but in practice, you're talking about
changes while the machine is running.

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

It's hard to disagree with such as noble and general statement but I don't see
how it relates to any of the particular changes you propose.

I don't see that any of the proposed changes make material progress towards or
away from "creating a strong central core" or why de-emphasizing the "past" is
such a good thing.

I certainly don't agree that there's "clear advantage" to dinking with the
builtins.  Rather there appears to be clear risk and unjustifiable cost.

It truly seems to me that for some reason you're really itching to make this
change and you're having trouble coming up with truly objective rationale for
doing so.

Again, when we're talking about a major improvement to the language, such as
lexical scope, then may well be worth a little pain.  But the fact that we have
a way to gracefully phase in vitally important major changes should not be
abused for gratuitous little tweaks.

> there is a powerful intellectual advantage to mentally whittling down
> the list of tools to a well integrated, orthogonal, best-of-class set.

Again you make a statement of personal opinion that is quite the opposite from
obvious.

If the number of basic "tools" was, say 10, and you were proposing to narrow the
list down to the best 7, there MIGHT arguably be clear advantage.  E.g., if this
changed crossed some theoretical threshold that genuinely made the whole list
easier for people to learn and remember.

However, when builtins already consists of scores of discrete functions and this
is in the context of a language with literally hundreds upon hundreds of other
fundamental operators, functions and datatypes to learn, you don't really
accomplish ANYTHING that I can see by dinking with one or two builtins.

It's even sillier when dozens of redundant forms remain in the language.  At the
end of the day, it's completely subjective whether any particular particle of
redundancy is good and which is bad.  List Comprehensions are kind'a cool but
they're completely redundant with other ways of doing things.  And for a lot of
newbies, a regular for loop will be a whole lot clearer.

A little bit of redundancy is no big deal.

I worry even more when there seems to be some hidden agenda that these changes
are to enforce certain styles of programming over others.  E.g., the prejudice
against FP expressed by some (not necessarily you).  Who's to say your view of
what's "right" for everybody is truly right?  What's the problem with a little
FP now and again?  Too, some people seem to confuse FP with deeply nested
expressions.

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

<gentle sarcasm>
And we'll get better gas mileage and loose weight in the process.
</gentle sarcasm>

I mean really, listen to yourself.  You're seriously arguing that the relatively
inconsequential change of moving a couple "old" functions to a separate section
of the DOCUMENTATION will materially affect the quality of programs and newbie
learning and that not making this change is preventing Python from advancing.

I respectfully have to disagree.

Respectfully yours,

--jb

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