[Python-Dev] PEP 3148 ready for pronouncement

[Dirkjan Ochtman]

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