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

Brian Quinlan brian at sweetapp.com
Sun May 23 13:02:48 CEST 2010

On May 23, 2010, at 8:43 PM, Dirkjan Ochtman wrote:

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 API is simple but writing a JSON parser is hard enough that people
will check to see if someone has already done the work for them
(especially since JSON is fairly topical).

If you are familiar with threads then writing a "good enough" solution
without futures probably won't take you very long. Also, unless you
are familiar with another futures implementation, you aren't likely to
know where to look.

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).

Some changes are hard (i.e. changing the semantics of existing method)
but some are pretty easy (i.e. adding new methods).

Cheers, Brian

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.

More information about the Python-Dev mailing list