On May 23, 2010, at 8:43 PM, Dirkjan Ochtman wrote:
On Sun, May 23, 2010 at 12:15, Brian Quinlan <br...@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.
_______________________________________________
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
