On Nov 6, 2008, at 12:14 PM, Barry Warsaw wrote:
As I see it, there are 3 options:
1. Hold up 3.0 until you get an API for the email package that
handles
Unicode vs bytes issues gracefully
2. Drop the email package entirely from 3.0, iterate on a 3.0
version of
it on PyPI for a while, then add the cleaned up version in 3.1
3. Keep the current version (issues and all) in 3.0, with fairly
strong
warnings that the API may change in 3.1
At this point I think our only option is essentially 3, keep what we
have warts and all. When the precursor to the email package was
being developed (at that time, called mimelib), it was initially
done as a separate package and only folded into core when it was
stable and fairly widely used.
For email-ng (or whatever we call it) we should follow the same
guidelines. Eventually email-ng will be folded back into the core
and will replace the current email package.
Is 3.1 in general going to allow API-breaking changes from 3.0? That's
fine with me if it is: it does make some sense to allow a "second
chance" to get things really right.
But if that's not the case, wouldn't it make more sense to keep email
out of the initial 3.0 release, rather than put a half-broken version
in with special "we can totally change the API for the next release"
dispensation?
James
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
