[Python-Dev] PEP 3148 ready for pronouncement

[Brian Quinlan]

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.