[stdlib-sig] Breaking out the stdlib
jnoller at gmail.com
Mon Sep 14 19:00:15 CEST 2009
On Mon, Sep 14, 2009 at 12:53 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le lundi 14 septembre 2009 à 12:19 -0400, Jesse Noller a écrit :
>> Sure, having batteries is fantastic. Until you being to realize that
>> some modules are broken, not up to date with current technology, etc,
>> etc. We have to be aggressive with cleaning it up.
>> Things within the stdlib must have a high quality bar, and should
>> really represent the "one way of doing something" - meaning best of
>> breed, high quality, idiomatic, etc.
> Have you read the thread about argparse and the deprecation of other
> You are conflating two things:
> 1. the presence of somewhat outdated or too low-level modules
> 2. the desire to have best-of-breed options available in the stdlib
> We can do 2. without undoing 1. As Marc-André pointed out, even in py3k
> we only deprecated a handful of very marginal modules. Emphasizing the
> right modules in the documentation is probably a reasonably good answer
> to the problem of having several modules fulfilling the same needs. No
> need to go on a deprecation frenzy and start annoying the two thirds of
> our user base just because we decided to be pure rather than practical.
IMHO, and in the opinions of others, the deprecation within py3k did
not go far enough.
This is not purity vs. practicality. In fact I'd argue (and will! I'm
warnin ya!) that leaving stuff in there because we don't want to
remove it for fear some other piece of code in the wild may depend on
it is completely impractical.
We do not have the people, the time, the funding, etc to handle a
great big Java-esque pile of "permanently deprecated, slightly
If we do not want it in the stdlib, it should be deprecated; and then
removed. Leaving it there in perpetuity means some person, 5 years
after we deprecate it, will write code against it - which, by this
reasoning we will have to support for another 10 years, even *after*
it's no longer maintained.
More information about the stdlib-sig