[Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
Barry Warsaw
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
Version: $Revision$
Last-Modified: $Date$
Author: Barry Warsaw <ba...@python.org>
Status: Final
Type: Informational
Content-Type: text/x-rst
Created: 2011-11-09
Python-Version: 2.8
Abstract
========
This document describes the development and release schedule for Python 2.8.
Release Schedule
================
The current schedule is:
- 2.8 final Never
Official pronouncement
======================
There will never be an official Python 2.8 release.
Upgrade path
============
The official upgrade path from Python 2.7 is to Python 3.
Copyright
=========
This document has been placed in the public domain.
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:
Benjamin Peterson
> 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".
> Version: $Revision$
> Last-Modified: $Date$
> Author: Barry Warsaw <ba...@python.org>
> Status: Final
> Type: Informational
> Content-Type: text/x-rst
> Created: 2011-11-09
> Python-Version: 2.8
--
Regards,
Benjamin
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com
Amaury Forgeot d'Arc
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?
Amaury Forgeot d'Arc
Victor Stinner
> Hi,
>
> 2011/11/9 Barry Warsaw <ba...@python.org>
>
> > 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?
random.choice() should help in this case.
Victor
Barry Warsaw
>2011/11/9 Barry Warsaw <ba...@python.org>
>
>> 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
Ethan Furman
> 2011/11/9 Barry Warsaw <ba...@python.org>:
>> 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~
Barry Warsaw
>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".
Okay, it's a little tongue-in-cheek, but the practical reason is that I want
it to be the top hit when someone searches for "Python 2.8".
Cheers,
-Barry
Terry Reedy
> I think we should have an official pronouncement about Python 2.8,
http://python.org/download/releases/2.7.2/ (and similar) already say:
The Python 2.7 series is scheduled to be the last major version in the
2.x series before 2.x moves into an extended maintenance period.
If Guido is ready to "pound the final nail in the coffin", delete
'scheduled to be', and change "series before 2.x moves into" to "series.
2.x is in", fine with me. I am not sure a PEP is also needed, but OK,
with revision.
> and PEPs are as official as it gets 'round here.
> Thus I propose the following. If there are no objections<wink>,
There are ;-). The title is misleading, and the whole thing reads like
an April Fools Joke. If I were looking for information, I would be
slightly annoyed.
> PEP: 405
> Title: Python 2.8 Release Schedule
Title: Python 2.8 Will Never Happen
tells anyone searching what they need to know immediately. They would
only need to click on a link if they wanted to know 'why'.
> Version: $Revision$
> Last-Modified: $Date$
> Author: Barry Warsaw<ba...@python.org>
Guido should be the first author.
> Status: Final
> Type: Informational
So let us be informative from the title on.
> Content-Type: text/x-rst
> Created: 2011-11-09
> Python-Version: 2.8
>
> Abstract
> ========
>
> This document describes the development and release schedule for Python 2.8.
More non-informative teasing. Instead, I suggest replacing everything
with short, sweet, and informative.
Rationale
=========
For backward-compatibility reasons, the Python 2 series is burdened with
several obsolete and duplicate features that were removed in Python 3.
In addition, the primary character set was expanded from ascii to
unicode. While bug fixes continue for 2.7, new developments go into
Python 3.x versions.
--
Terry Jan Reedy
Brian Curtin
Paul Moore
>
> 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.
+1 on having a PEP
+0 on posting it as it stands
I see why people feel that something more precise and/or formal would
get the message across better, but the mildly tongue-in-cheek tone
isn't really inappropriate for a language named after Monty Python :-)
+1 for Cardinal Biggles as release manager.
Paul
John O'Connor
+1
Barry Warsaw
>I see why people feel that something more precise and/or formal would
>get the message across better, but the mildly tongue-in-cheek tone
>isn't really inappropriate for a language named after Monty Python :-)
*Thank you* :)
>+1 for Cardinal Biggles as release manager.
Brilliant!
-Barry
Nick Coghlan
>>+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 | ncog...@gmail.com | Brisbane, Australia
Barry Warsaw
>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? :)
>Getting boring for a moment, I suggest including the following new
>section just before the copyright section:
You have a very good point. I think I'd like a shorter 'serious' section
though. Let me see what I can put together.
-Barry
Greg Ewing
> Do we need to designate a release manager?
I nominate John Cleese. Although he's undoubtedly a busy
man, this shouldn't take up too much of his time.
--
Greg
Tim Delaney
On Nov 10, 2011, at 08:58 AM, Nick Coghlan wrote:Brilliant suggestion! Vinay? :)
>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 :)
anatoly techtonik
>
> Getting boring for a moment, I suggest including the following new
> section just before the copyright section:
I'd also include a "roadmap" section with all 2.x wannabes that are
not going to be be released with 2.8. And a special epilogue chapter
listing all missing stdlib wannabes and fixes that were never
implemented, because they break backward 2.x compatibility.
--
anatoly t.
Vinay Sajip
>
> 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 :-)
Regards,
Vinay Sajip
Carl Meyer
Hash: SHA1
On 11/10/2011 07:17 AM, Vinay Sajip wrote:
> Barry Warsaw <barry <at> python.org> 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-----
Lennart Regebro
> Hi,
> 2011/11/9 Barry Warsaw <ba...@python.org>
>>
>> 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