[Python-3000] Removing email package until it's fixed

[Gregory P. Smith]

On Sat, Aug 25, 2007 at 03:00:15PM -0700, Brett Cannon wrote:
> On 8/25/07, Fred Drake <fdrake at acm.org> wrote:
> > Alternately, we could move toward separate libraries for such
> > components; this allows separate packages to have separate
> > maintenance cycles, and makes it easier for applications to pick up
> > bug fixes.
> 
> Are you suggesting of just leaving email out of the core then and just
> have people download it as necessary?  Or just having it developed
> externally and thus have its own release schedule, but then pull in
> the latest stable release when we do a new Python release?
> 
> I don't like the former, but the latter is intriguing.  If we could
> host large packages (e.g., email, sqlite, ctypes, etc.) on python.org
> by providing tracker, svn, and web space they could be developed and
> released on their own schedule.  Then the Python release would then
> become a sumo release of these various packages.  People could release
> code that still depends on a specific Python version flatly (and thus
> not have external dependencies), or say it needs support of Python 2.6
> + email 42.2 or something if some feature is really needed).  But
> obviously this ups the resource needs on Python's infrastructure so I
> don't know how reasonable it really is in the end.
> 
> -Brett

Agreed, the latter of still pulling in the latest stable release when
doing a new Python release is preferred.  Libraries not included with
the standard library set in python distributions are much less likely
to be used because not all python installs will include them by default.

I think something better than 'latest stable release' of any given
module would make sense.  Presumably we'd want to keep up the no
features/API changes within a given Python 3.x releases standard
library?

Or would that just become "no backwards incompatible API changes" to
allow for new features; all such modules would need to include their
own version info.  In that case we should make it easy to specify an
API version at import time causing an ImportError if the API version
is not met.

brainstorm:

import spam api 3.0
from spam api 3.0 import eggs as chickens

import spam(3.0)
from spam(3.0) import eggs as chickens

it could get annoying to need to think much about package versions in
import statements.  its much less casual, it should not be required.

-gps