Third Draft: Pep for Deprecating Builtins

[Sean 'Shaleh' Perry]

>> >From the comments, I've learned:
>>
>> 5.  oct() is another candidate based on the rarity of usage
> 
> Candidate perhaps but some people still like Octal.
> 
> This still is a gratuitious change and thus should not be implemented.
> 
> If it ain't really broke, you shouldn't fix it.
> 

here here!

>> 7. the language needs some means of deprecating so that clutter
>>     does accumulate.  that means needs to be well documented,
>>     have a long, slow phase-in, and have a mechasism for
>>     restoring old behavior if it is ever needed.
> 
> Making it easier to phase changes in and out makes things easier only
> for the most active Python users.  Changes themselves are hard on the
> user base generally.  Furthermore, having a language where things like
> base functionality routinely changes significantly from release to
> release seems a Bad Thing.
> 
> Picture the poor newbie sitting down with his O'Reilly book, having just
> installed 2.3 or 2.4 and can't figure out why some of the examples no
> longer work.  O'Reilly has how many thousands of these books in the
> pipeline?  I'm sure they're not anxious to issue a revised edition.
> Steve Holden barely had time to get get the 2.1 appendix in his book.
> This is not helping ANYBODY.
> 
> I frankly think it's ALARMING that people are becomming comfortable with
> the notion that you can't interpret the meaning of programs without (a)
> being up to date on how things change from release to release and (b)
> paying close attention to the declarations or (super ugh) command
> switches that might override defaults.  This is a much greater burden
> than simply learning any particular version of the language.  It's a
> moving target.  Of course users don't have to upgrade to each new
> release and generally only use one version at a time.  But in trying to
> use other people's code you're likely to encounter anything from old to
> new, so you have the problem whether you want it or not.  Unless you
> hide in your hole and only use code you write yourself.
> 

The problem is compounded when you are not in control of the python on the
system.  Imaging CGIs broken when the person's ISP decides to upgrade their
machines to a new OS rev which has a new python.