[Python-Dev] Dead modules

[Antoine Pitrou]

On Sun, 23 May 2010 12:43:57 +0200
Dirkjan Ochtman  wrote:
> 
> In general, this reminds me of the ipaddr discussions. I read through
> the thread from March real quick to see if there was reasoning there
> why this package should be an exception from the "normal" standards
> track (that is, ripen on PyPI, then moving it in the stdlib when it's
> mature -- where "mature" is another word for dead, really).

I disagree that a stdlib module is a dead module. It is perfectly
possible to augment the API with new functionality without breaking
compatibility. You can also deprecate old APIs if you want.

Regards

Antoine.


___
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

Re: [Python-Dev] Dead modules

[Dirkjan Ochtman]

On Sun, May 23, 2010 at 12:51, Antoine Pitrou  wrote:
> I disagree that a stdlib module is a dead module. It is perfectly
> possible to augment the API with new functionality without breaking
> compatibility. You can also deprecate old APIs if you want.

Right, it wasn't intended as that harsh... but it does come with a
rather impressive set of constraints in terms of what you can do with
the API.

Cheers,

Dirkjan
___
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

Re: [Python-Dev] Dead modules

[Nick Coghlan]

(Sending again - I didn't mean to drop python-dev from the cc list when 
I originally sent this via the gmail web interface)


On Sun, May 23, 2010 at 9:00 PM, Dirkjan Ochtman > wrote:


   Right, it wasn't intended as that harsh... but it does come with a
   rather impressive set of constraints in terms of what you can do with
   the API.

True, but in some cases (especially low level infrastructure), it is 
worth accepting those constraints in order to achieve other aims (such 
as standardisation of techniques). Things like itertools, collections, 
functools, unittest owe their existence largely to the choice of gains 
in standardisation over flexibility of API updates.
Besides, popular PyPI modules don't have that much more freedom than the 
stdlib when it comes to API changes. The only real difference is that 
the 18-24 month release cycle for the stdlib is a lot *slower* than that 
of many PyPI packages, so feedback on any changes we make is 
correspondingly delayed. Hence the existence of projects like distutils2 
and unittest2 to enable that faster feedback cycle to inform the updates 
passed back into the more slowly evolving stdlib modules, as well as the 
desire to copy prior art wherever it makes sense to do so (whether that 
is other languages, existing PyPI modules or the internal code bases of 
large corporate contributors).


Cheers,
Nick.
___
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