[Python-Dev] PEP 3148 ready for pronouncement (original) (raw)

Dirkjan Ochtman dirkjan at ochtman.nl
Sun May 23 12:43:57 CEST 2010

On Sun, May 23, 2010 at 12:15, Brian Quinlan <brian at sweetapp.com> wrote:

I doubt it. Simple modules are unlikely to develop a following because it is too easy to partially replicate their functionality. urlparse and os.path are very useful modules but I doubt that they would have been successful on PyPI.

simplejson was also fairly simple, but still developed a following.

The good news in this case is that the same API has been used successfully in Java and C++ for years so it is unlikely that any major changes will need to be made.

I would agree that having prior versions in other languages should make the API more stable, but I wouldn't agree that it doesn't need changes (and even minor changes can be a PITA in the stdlib).

Also, you can't fix bugs except by releasing new versions of Python. Therefore the API must be completely stable, and the product virtually bugfree before it should be in stdlib. The best way of ensuring that is to release it as a separate module on PyPI, and let it stabilize for a couple of years. Yeah but that model isn't likely to work with this package.

Okay, I'll bite: why is your package different?

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). But then this is just another instance of the fat-stdlib vs lean-stdlib discussion, I guess, so we can go on at length.

Cheers,

Dirkjan

More information about the Python-Dev mailing list