On Sat, Aug 25, 2007 at 03:00:15PM -0700, Brett Cannon wrote: > On 8/25/07, Fred Drake <[EMAIL PROTECTED]> 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 _______________________________________________ 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
