On 26/05/10 20:56, Antoine Pitrou wrote:
On Wed, 26 May 2010 20:42:12 +1000
Steven D'Aprano<st...@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 | ncogh...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
