Benjamin Peterson wrote:

2011/11/9 Barry Warsaw :

...

I think we should have an official pronouncement about Python 2.8, and PEPs are as official as it gets 'round here. Thus I propose the following. If there are no objections <wink>, I'll commit this taking the next available number.

Cheers, -Barry

PEP: 405 Title: Python 2.8 Release Schedule

I don't know why this PEP is necessary, but I think a more appropriate title would be "2.x is in maintenance only mode".

I think somebody searching will more easily find "Python 2.8 Release Schedule" rather than "2.x is in maintenance only mode". ~Ethan~

On Nov 09, 2011, at 05:18 PM, Amaury Forgeot d'Arc wrote:

2011/11/9 Barry Warsaw

...

I think we should have an official pronouncement about Python 2.8, and PEPs are as official as it gets 'round here.

Do we need to designate a release manager?

I'd happily serve as the un-release manager. :) -Barry

On Wed, Nov 9, 2011 at 17:18, Amaury Forgeot d'Arc wrote:

Hi, 2011/11/9 Barry Warsaw

...

I think we should have an official pronouncement about Python 2.8, and PEPs are as official as it gets 'round here.

Do we need to designate a release manager?

I volunteer. It's on my level of competence. //Lennart

+1 for Cardinal Biggles as release manager.

+1

On Thu, Nov 10, 2011 at 7:55 AM, Barry Warsaw wrote:

...

+1 for Cardinal Biggles as release manager.

Now you need to persuade Vinay to let you trade PEP numbers with the pyvenv PEP. Having an unrelease schedule as PEP 404 is too good an opportunity to pass up :) Getting boring for a moment, I suggest including the following new section just before the copyright section: And Now For Something Completely Different ================================= Sorry, sorry, that's just being too silly. While the language may be named after a British comedy troupe (and the overall tone of this PEP reflects that), there are some serious reasons that explain why there won't be an official 2.8 release from the CPython development team. If a search for "Python 2.8" brought you to this document, you may not be aware of the underlying problems in the design of Python 2.x that led to the creation of the 3.x series. First and foremost, Python 2.x is a language with ASCII text at its core. The main text manipulation interfaces, the standard I/O stack and many other elements of the standard library are built around that assumption. While Unicode is supported, it's quite clearly an added on feature rather than something that is fundamental to the language. Python 3.x changes that core assumption, instead building the language around Unicode text. This affects the builtin ``str`` type (which is now Unicode text rather than 8-bit data), the standard I/O stack (which now supports Unicode encoding concepts directly), what identifier and module names are legal (with most Unicode alphanumeric characters being supported) and several other aspects of the language. With the text handling and associated I/O changes breaking backwards compatibility *anyway*, Guido took the opportunity to finally eliminate some other design defects in Python 2.x that had been preserved solely for backwards compatibility reasons. These changes include: - complete removal of support for "classic" (i.e. pre-2.2 style) class semantics - the separate ``int`` (machine level integer) and ``long`` (arbitrarily large) integer types have been merged into a single ``int`` type (that supports arbitrarily large values) - integer division now promotes non-integer results to binary floating values automatically - the error prone ``except Exception, exc:`` syntax has been removed (in favour of the more explicit ``except Exception as exc:``) - ``print`` and ``exec`` are now ordinary functions rather than statements - the backtick based ```x``` alternate spelling of ``repr(x)`` has been removed - the ``<>`` alternate spelling of ``!=`` has been removed - implicit relative imports have been removed - star imports (i.e. ``from x import *``) are now permitted only in module level code - implicit ordering comparisons between objects of different types have been removed - list comprehensions no longer leak their iteration variables into the surrounding scope - many APIs that previously returned lists now return iterators or lightweight views instead (e.g. ``map`` produces an iterator, ``range`` creates a virtual sequence, ``dict.keys`` a view of the original dict) - iterator advancement is now via a protocal-based builtin (``next()`` invoking ``__next__()``) rather than an ordinary method call - some rarely needed builtins have been relocated to standard library modules (``reduce`` is now ``functools.reduce``, ``reload`` is now ``imp.reload``) - some areas of the standard library have been rearranged in an attempt to make the naming schemes more intuitive More details on the backwards incompatible changes relative to the 2.x series can be found in the `Python 3.0 What's New`_ document. With the 3.x Unicode based architecture providing a significantly better foundation for a language with a global audience, all new features will appear solely in the Python 3.x series. However, as detailed elsewhere, the 2.7 release will still be supported with bug fixes and maintenance releases for several years. .. _`Python 3.0 What's New`: http://docs.python.org/py3k/whatsnew/3.0.html -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On 10 November 2011 11:05, Barry Warsaw wrote:

On Nov 10, 2011, at 08:58 AM, Nick Coghlan wrote:

...

Now you need to persuade Vinay to let you trade PEP numbers with the pyvenv PEP. Having an unrelease schedule as PEP 404 is too good an opportunity to pass up :)

Brilliant suggestion! Vinay? :)

410 Gone would be more appropriate IMO. But 404 does have more mindshare. Tim Delaney

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/10/2011 07:17 AM, Vinay Sajip wrote:

Barry Warsaw writes:

...

On Nov 10, 2011, at 08:58 AM, Nick Coghlan wrote:

...

Now you need to persuade Vinay to let you trade PEP numbers with the pyvenv PEP. Having an unrelease schedule as PEP 404 is too good an opportunity to pass up :)

Brilliant suggestion! Vinay? :)

Actually you need Carl Meyer's agreement, not mine - he's the one writing the PEP. But I'm in favour :-)

No objection here. Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk68DeYACgkQ8W4rlRKtE2c9pACgvYw22k3HQOgjmRjNk+F5AdW4 QIcAoLgzdPb8PNNHqqEdGYWGeMp0lD3I =u9HS -----END PGP SIGNATURE-----