[Python-Dev] PEP 3148 ready for pronouncement

Michael Foord fuzzyman at voidspace.org.uk
Wed May 26 14:28:38 CEST 2010


On 26/05/2010 13:19, Paul Moore wrote:
> On 26 May 2010 11:56, Antoine Pitrou<solipsis at pitrou.net>  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)
>>      
> I'm not sure how a "Sumo" approach would work in practical terms, and
> this thread isn't really the place to discuss, but there's a couple of
> points I think are worth making:
>
> * For a "Sumo" distribution to make sense, some relatively substantial
> chunk of the standard library would need to be moved *out* to reside
> in the sumo distribution. Otherwise it's not really a "sumo", just a
> couple of modules that "nearly made it into the stdlib", at least for
> the near-to-medium term. I've yet to see any sort of consensus that
> python-dev is willing to undertake that decoupling work. (Which would
> include extracting the various tests, migrating bugs out of the
> pythion tracker, etc etc).
>
> * If the decoupled modules aren't simply being abandoned, python-dev
> needs to continue to commit to supporting them "in the wild" (i.e., on
> PyPI and in the sumo distribution). Otherwise we're just abandoning
> existing users and saying "support it yourself". I've seen no
> indication that python-dev members would expect to follow bug trackers
> for various decoupled modules - so in practice, this sounds more like
> abandonment than decoupling.
>
> Until a stdlib-decoupling proposal which takes these aspects into
> account is on the table, I'm afraid that suggesting there's a "Sumo
> distribution" style middle ground between stdlib and PyPI isn't really
> true...
>    

Well... a middle ground certainly could exist; perhaps in the form of an 
"Extended Standard Library" (community distribution), with simple 
installation and management tools.

It could be "blessed" by python-dev and maintain a high standard (only 
well established best-of-breed modules with a commitment of ongoing 
maintenance and more than one maintainer - something that the stdlib 
itself doesn't stick to). A common license could even be chosen, 
potentially allowing corporations to approve the extended package in a 
single pass.

Lot of details to flesh out obviously - but it would be great to see 
something like this come into being. Obviously this would need to be a 
community initiative and would take some time to establish. A "fat" 
distribution like this, based on tools like pip and distribute would be 
great for both newbies and for experienced programmers in making it 
easier to find "best" solutions for standard problems. It could also act 
as an incubator for the standard library (perhaps with stable and 
experimental streams where stable has a more conservative update policy).

All the best,

Michael Foord
> Paul.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.




More information about the Python-Dev mailing list