[Python-Dev] PEP 3148 ready for pronouncement

[Nick Coghlan]

On 26/05/10 20:56, Antoine Pitrou wrote:
> On Wed, 26 May 2010 20:42:12 +1000
> Steven D'Aprano<steve at pearwood.info>  wrote:
>>
>> I'm not saying that Python-Dev should bend over backwards to accommodate
>> such people to the exclusion of all else, but these folks are
>> stakeholders too, and their wants and needs are just as worthy as the
>> wants and needs of those who prefer a more conservative approach to the
>> standard library.
>
> Well, my "Sumo" proposal was a serious one.
> (not serious in that I would offer to give a hand, but in that I think
> it could help those people; also, wouldn't it be sensible for users in
> a corporate environment to share their efforts and produce something
> that can benefit all of them? it's the free software spirit after all)

That's actually what happens with groups like Enthought and ActiveState 
- bundles with extra batteries.

However, note that this isn't just a dysfunctional corporate culture 
issue, and I object to it being characterised as such (although 
dysfunctional cultures can certainly make it much, much worse). Vetting 
licenses for due diligence reasons, tracking releases of an external 
module, familiarising yourself with an additional API and code base, the 
risk of encountering bugs in that code base... these are all real costs 
that don't go away no matter how good the Python packaging ecosystem 
becomes. There is a trade off between "do the simplest thing that could 
possibly work (but may cause you problems later)" and spending the time 
to investigate third party solutions (with the risk that you end up 
rolling your own later anyway if you don't find anything suitable or, 
worse, find something that initially seems suitable but proves 
unworkable in practice).

A module that makes it into the standard library, however, carries 
python-dev's stamp of approval. Except for some older legacy libraries, 
that means a module will have at least half decent documentation and an 
automated test suite that is regularly run on multiple platforms. Its 
design will also have run the gauntlet of python-dev approval.

If we identify a good solution to a standard problem, and we have reason 
to believe that posting it in on PyPI as a separate module won't lead to 
a significant amount of additional real world testing, then it makes 
sense for it to go straight into the standard library.

Such modules are going to be rare (since most non-trivial modules *will* 
benefit from some time on PyPI, and most trivial modules won't be added 
to the standard library at all), but they do exist (runpy, contextlib, 
collections, itertools and abc spring to mind).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------