Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Fix typo
Do you mean something like: «Let's also change the rest of the program to make the new functionality:» ??? On Sat, Apr 6, 2013 at 6:41 AM, Eli Bendersky wrote: > > On Fri, Apr 5, 2013 at 1:40 AM, andrew.svetlov > wrote: >> >> http://hg.python.org/cpython/rev/6cf485ffd325 >> changeset: 83110:6cf485ffd325 >> parent: 83106:94fb906e5899 >> parent: 83109:9610ede72ed2 >> user:Andrew Svetlov >> date:Fri Apr 05 11:40:01 2013 +0300 >> summary: >> Fix typo >> >> files: >> Doc/howto/argparse.rst | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> >> diff --git a/Doc/howto/argparse.rst b/Doc/howto/argparse.rst >> --- a/Doc/howto/argparse.rst >> +++ b/Doc/howto/argparse.rst >> @@ -668,7 +668,7 @@ >> So far, we have been working with two methods of an >> :class:`argparse.ArgumentParser` instance. Let's introduce a third one, >> :meth:`add_mutually_exclusive_group`. It allows for us to specify options >> that >> -conflict with each other. Let's also change the rest of the program make >> the >> +conflict with each other. Let's also change the rest of the program to >> make the >> new functionality makes more sense: > > > > Andrew, while you're at it you can also fix the rest of the sentence, which > makes no sense ;-) > > Eli > -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Fix typo
It currently says: "Let's also change the rest of the program to make the new functionality makes more sense" This can be changed to: "Let's also change the rest of the program so that the new functionality makes more sense". Eli On Sat, Apr 6, 2013 at 7:25 AM, Andrew Svetlov wrote: > Do you mean something like: > «Let's also change the rest of the program to make the new functionality:» > ??? > > > On Sat, Apr 6, 2013 at 6:41 AM, Eli Bendersky wrote: > > > > On Fri, Apr 5, 2013 at 1:40 AM, andrew.svetlov < > [email protected]> > > wrote: > >> > >> http://hg.python.org/cpython/rev/6cf485ffd325 > >> changeset: 83110:6cf485ffd325 > >> parent: 83106:94fb906e5899 > >> parent: 83109:9610ede72ed2 > >> user:Andrew Svetlov > >> date:Fri Apr 05 11:40:01 2013 +0300 > >> summary: > >> Fix typo > >> > >> files: > >> Doc/howto/argparse.rst | 2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) > >> > >> > >> diff --git a/Doc/howto/argparse.rst b/Doc/howto/argparse.rst > >> --- a/Doc/howto/argparse.rst > >> +++ b/Doc/howto/argparse.rst > >> @@ -668,7 +668,7 @@ > >> So far, we have been working with two methods of an > >> :class:`argparse.ArgumentParser` instance. Let's introduce a third one, > >> :meth:`add_mutually_exclusive_group`. It allows for us to specify > options > >> that > >> -conflict with each other. Let's also change the rest of the program > make > >> the > >> +conflict with each other. Let's also change the rest of the program to > >> make the > >> new functionality makes more sense: > > > > > > > > Andrew, while you're at it you can also fix the rest of the sentence, > which > > makes no sense ;-) > > > > Eli > > > > > > -- > Thanks, > Andrew Svetlov > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] give IDLE its own NEWS section?
I noticed IDLE changes were being put under the "library" section in Misc/NEWS. How about creating a IDLE section? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Fix typo
Done, thanks On Sat, Apr 6, 2013 at 5:41 PM, Eli Bendersky wrote: > It currently says: > > "Let's also change the rest of the program to make the new functionality > makes more sense" > > This can be changed to: > > "Let's also change the rest of the program so that the new functionality > makes more sense". > > Eli > > > > > On Sat, Apr 6, 2013 at 7:25 AM, Andrew Svetlov > wrote: >> >> Do you mean something like: >> «Let's also change the rest of the program to make the new functionality:» >> ??? >> > > > > >> >> On Sat, Apr 6, 2013 at 6:41 AM, Eli Bendersky wrote: >> > >> > On Fri, Apr 5, 2013 at 1:40 AM, andrew.svetlov >> > >> > wrote: >> >> >> >> http://hg.python.org/cpython/rev/6cf485ffd325 >> >> changeset: 83110:6cf485ffd325 >> >> parent: 83106:94fb906e5899 >> >> parent: 83109:9610ede72ed2 >> >> user:Andrew Svetlov >> >> date:Fri Apr 05 11:40:01 2013 +0300 >> >> summary: >> >> Fix typo >> >> >> >> files: >> >> Doc/howto/argparse.rst | 2 +- >> >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> >> >> >> >> diff --git a/Doc/howto/argparse.rst b/Doc/howto/argparse.rst >> >> --- a/Doc/howto/argparse.rst >> >> +++ b/Doc/howto/argparse.rst >> >> @@ -668,7 +668,7 @@ >> >> So far, we have been working with two methods of an >> >> :class:`argparse.ArgumentParser` instance. Let's introduce a third >> >> one, >> >> :meth:`add_mutually_exclusive_group`. It allows for us to specify >> >> options >> >> that >> >> -conflict with each other. Let's also change the rest of the program >> >> make >> >> the >> >> +conflict with each other. Let's also change the rest of the program to >> >> make the >> >> new functionality makes more sense: >> > >> > >> > >> > Andrew, while you're at it you can also fix the rest of the sentence, >> > which >> > makes no sense ;-) >> > >> > Eli >> > >> >> >> >> -- >> Thanks, >> Andrew Svetlov > > -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] give IDLE its own NEWS section?
Am 06.04.2013 16:58, schrieb Benjamin Peterson: > I noticed IDLE changes were being put under the "library" section in > Misc/NEWS. How about creating a IDLE section? There is also Lib/idlelib/NEWS.txt. It also contains IDLE news items and is shown in a dialog box from within IDLE. IMO it's fine for changelog entries to go there exclusively. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantics of __int__(), __index__()
On 4/4/2013 10:04 PM, Steven D'Aprano wrote:
When I call int(), I'm expecting an int.
We agree so far...,
> That includes well-behaved subclasses of int that continue to behave
> like ints in all the ways that matter.
but not here. I currently expect an actual int instance for 3 reasons.
1. As I read the doc, that is the currently documented 'should'.
2. I believe class constructors should, generally, return an instance of
the class, in the narrow sense, and that factory functions should,
generally, be used to return instances of multiple classes. The multiple
classes would typically, or at least often, all be subclasses of some
baseclass.
3. Most apropos to your next paragraph: *because* Python is duck-typed,
I would not replace a function arg that might be an int subclass with
int(arg) unless (I thought) the difference would make a difference.
Lets consider cases:
1. int(non-scalar-number): this is usually an error, except for bytes or
unicode strings that represents a number in standard base-[2-32]
notation. int has builtin knowledge of these two builtin classes. One
can add an __int__ method to string subclasses that represent integers
with non-standard notation.
A common use is int(input(prompt)) or int(other-external-input).
2. int(rational): for floats, Fractions, and Decimals, this returns the
integral part, truncating toward 0. Decimal and float have __int__
methods. Fractions, to my surprise, does not, so int must use __floor__
or __round__ as a backup.
I believe we have no disagreement that int() should return an int for
these cases. Here is a possible use for input checking.
def fib(n):
"return fibonnaci(integral input); return type == input type"
if int(n) != n or n < 0:
raise TypeError('fib input must be a count')
# let int() or < exception propagate
# the input check is needed to prevent infinite looping
return fib-of-n
Because of duck-typing, there is no need to replace n with int(n). The
return type will be the input type.
3. int(int-subclass-instance): If the int subclass instances behave like
an int in all ways that matter in the context, there is no reason to
specifically do. In other words, this use should be very rare, such as
wanting the int repr. I am also not sure, without checking the doc for
the definition of the bit operations, if all int subclasses would
dependably substitute in bit manipulations. So unless you can give a
good reason otherwise, I think the subclass .__int__ class should assume
that the programmer might actually specifically want an int instance.
In the example above, int() is part of a general case 2 input check that
non-negative subclass instances should pass whether they return
themselves or an int.
It's curious to see the (d)evolution of thinking on type checking in
Python circles. Once upon a time, type checking was discouraged,
duck-typing was encouraged, and the philosophy was that an int is
anything that behaves like an int.
I always differentiated 'int' as a type/class int object from 'integer'
as anything that behaves like an 'int'. For me, and the function
outlined above, that includes integer-values rationals along with int
subclass instances.
Now type-checking is tolerated or
even encouraged, provided that you use isinstance,
I seem to have missed the encouragement.
> and an int is anything that inherits from the builtin (or the ABC).
And this proposed change in behaviour
To conform to how come read the doc..
> continues the move away from Python's former emphasis on duck-typing.
For the reason explained above, I do not see this issue in such
apocalyptic terms ;-)
--
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] give IDLE its own NEWS section?
On 06.04.13 17:58, Benjamin Peterson wrote: I noticed IDLE changes were being put under the "library" section in Misc/NEWS. How about creating a IDLE section? http://bugs.python.org/issue17221 http://bugs.python.org/issue17506 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] give IDLE its own NEWS section?
Having gotten positive input from Todd, I've now done the move. 2013/4/6 Benjamin Peterson : > I noticed IDLE changes were being put under the "library" section in > Misc/NEWS. How about creating a IDLE section? > > -- > Regards, > Benjamin -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASE] Python 2.7.4
I'm thrilled to announce the release of Python 2.7.4. 2.7.4 is the latest maintenance release in the Python 2.7 series. It includes hundreds of bugfixes to the core language and standard library. Downloads are at http://python.org/download/releases/2.7.4/ As always, please report bugs to http://bugs.python.org/ Several regressions found in the release candidate have been fixed. Many thanks to those who tested the preview release. There has recently been a lot of discussion about XML-based denial of service attacks. Specifically, certain XML files can cause XML parsers, including ones in the Python stdlib, to consume gigabytes of RAM and swamp the CPU. 2.7.4 does not include any changes in Python XML code to address these issues. Interested parties should examine the defusedxml package on PyPI: https://pypi.python.org/pypi/defusedxml This is a production release. Best wishes, Benjamin Peterson 2.7 Release Manager (on behalf of all of Python 2.7's contributors) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantics of __int__(), __index__()
On Fri, Apr 5, 2013 at 6:34 PM, Terry Jan Reedy wrote: > 2. int(rational): for floats, Fractions, and Decimals, this returns the > integral part, truncating toward 0. Decimal and float have __int__ methods. > Fractions, to my surprise, does not, so int must use __floor__ or __round__ > as a backup. > It uses __trunc__, which is supposed to be the unambiguous "Yes I really want to throw away the fractional part and risk losing information" replacement for __int__. int() will try __int__ first, and then __trunc__, as per PEP 3141. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.2.4 and Python 3.3.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I am pleased to announce the final releases of Python 3.2.4 and 3.3.1. Python 3.2.4 is the final regular maintenance release for the Python 3.2 series, while Python 3.3.1 is the first maintenance release for the 3.3 series. Both releases include hundreds of bugfixes. There has recently been a lot of discussion about XML-based denial of service attacks. Specifically, certain XML files can cause XML parsers, including ones in the Python stdlib, to consume gigabytes of RAM and swamp the CPU. These releases do not include any changes in Python XML code to address these issues. Interested parties should examine the defusedxml package on PyPI: https://pypi.python.org/pypi/defusedxml To download Python 3.2.4 or Python 3.3.1, visit: http://www.python.org/download/releases/3.2.4/ or http://www.python.org/download/releases/3.3.1/ respectively. As always, please report bugs to http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and all contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFgiN8ACgkQN9GcIYhpnLAXxQCdHAd2lECpYfmYM4Wbd3I01es4 898AoKBDvHtgecD/PeVRKUrdQRSWGPJg =K8RQ -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] The end of 2.7
Per my last message, 2.7.4 has at long last been released. I apologize for the long interval between 2.7.3 and 2.7.4. To create more determinism in the future, I will be soon updating PEP 373 with approximate dates of future 2.7 bugfix releases. I will be aiming for 6 month intervals. This means we need to talk about how many more 2.7 releases there are going to be. At the release of 2.7.0, I thought we promised 5 years of bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0 was released in July 2010, which currently puts us within a few months of 3 years of maintenance. Over the past year, I've been happy to see a lot of movement towards 3 including the porting of important codebases like Twisted and Django. However, there's also no doubt that 2.x is still widely used. Obviously, there will be people who would be happy if we kept maintaining 2.7 until 2025, but I think at this juncture 5 total years of maintenance is reasonable. This means there will be approximately 4 more 2.7 releases. Thoughts? Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
Am 06.04.2013 23:02, schrieb Benjamin Peterson: > Per my last message, 2.7.4 has at long last been released. I apologize > for the long interval between 2.7.3 and 2.7.4. To create more > determinism in the future, I will be soon updating PEP 373 with > approximate dates of future 2.7 bugfix releases. I will be aiming for > 6 month intervals. > > This means we need to talk about how many more 2.7 releases there are > going to be. At the release of 2.7.0, I thought we promised 5 years of > bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0 > was released in July 2010, which currently puts us within a few months > of 3 years of maintenance. Over the past year, I've been happy to see > a lot of movement towards 3 including the porting of important > codebases like Twisted and Django. However, there's also no doubt that > 2.x is still widely used. Obviously, there will be people who would be > happy if we kept maintaining 2.7 until 2025, but I think at this > juncture 5 total years of maintenance is reasonable. This means there > will be approximately 4 more 2.7 releases. > > Thoughts? I agree that keeping to 5 years of official maintenance releases is reasonable at present. However, in 2015 I can well imagine offers from group(s) in the community to maintain the 2.7 branch with fixes ported from 3.x. At that point, we will have to decide how to treat releases from this "backports" branch. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
On Sat, 6 Apr 2013 17:02:17 -0400 Benjamin Peterson wrote: > Obviously, there will be people who would be > happy if we kept maintaining 2.7 until 2025, but I think at this > juncture 5 total years of maintenance is reasonable. This means there > will be approximately 4 more 2.7 releases. > > Thoughts? That's quite fine with me. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
Am 06.04.2013 23:11, schrieb Georg Brandl: > Am 06.04.2013 23:02, schrieb Benjamin Peterson: >> Per my last message, 2.7.4 has at long last been released. I apologize >> for the long interval between 2.7.3 and 2.7.4. To create more >> determinism in the future, I will be soon updating PEP 373 with >> approximate dates of future 2.7 bugfix releases. I will be aiming for >> 6 month intervals. >> >> This means we need to talk about how many more 2.7 releases there are >> going to be. At the release of 2.7.0, I thought we promised 5 years of >> bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0 >> was released in July 2010, which currently puts us within a few months >> of 3 years of maintenance. Over the past year, I've been happy to see >> a lot of movement towards 3 including the porting of important >> codebases like Twisted and Django. However, there's also no doubt that >> 2.x is still widely used. Obviously, there will be people who would be >> happy if we kept maintaining 2.7 until 2025, but I think at this >> juncture 5 total years of maintenance is reasonable. This means there >> will be approximately 4 more 2.7 releases. >> >> Thoughts? > > I agree that keeping to 5 years of official maintenance releases is > reasonable at present. > > However, in 2015 I can well imagine offers from group(s) in the community > to maintain the 2.7 branch with fixes ported from 3.x. At that point, > we will have to decide how to treat releases from this "backports" branch. Five years official releases sounds fine to me, too. Martin, how long are you going to build official Windows binaries for Python 2.7? Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
I agree with Benjamin though is it really necessary to do two 2.7 releases a year for the last two years? that's rather rapid (but as the release manager its your call). A few of us (sorry I forgot who all was there though I think Martin was?) had a discussion at PyCon a few weeks ago and seemed to think that a state of affairs where a 2.7.5 release one year-ish from now would be fine as the last _binary_ release but that continuing to make a 2.7.6 and beyond as source only releases was reasonable. Regardless, the 5 years of 2.7 supported releases plan still makes sense regardless of release binaries being available for windows and mac or not. -gps On Sat, Apr 6, 2013 at 3:05 PM, Christian Heimes wrote: > Am 06.04.2013 23:11, schrieb Georg Brandl: > > Am 06.04.2013 23:02, schrieb Benjamin Peterson: > >> Per my last message, 2.7.4 has at long last been released. I apologize > >> for the long interval between 2.7.3 and 2.7.4. To create more > >> determinism in the future, I will be soon updating PEP 373 with > >> approximate dates of future 2.7 bugfix releases. I will be aiming for > >> 6 month intervals. > >> > >> This means we need to talk about how many more 2.7 releases there are > >> going to be. At the release of 2.7.0, I thought we promised 5 years of > >> bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0 > >> was released in July 2010, which currently puts us within a few months > >> of 3 years of maintenance. Over the past year, I've been happy to see > >> a lot of movement towards 3 including the porting of important > >> codebases like Twisted and Django. However, there's also no doubt that > >> 2.x is still widely used. Obviously, there will be people who would be > >> happy if we kept maintaining 2.7 until 2025, but I think at this > >> juncture 5 total years of maintenance is reasonable. This means there > >> will be approximately 4 more 2.7 releases. > >> > >> Thoughts? > > > > I agree that keeping to 5 years of official maintenance releases is > > reasonable at present. > > > > However, in 2015 I can well imagine offers from group(s) in the community > > to maintain the 2.7 branch with fixes ported from 3.x. At that point, > > we will have to decide how to treat releases from this "backports" > branch. > > Five years official releases sounds fine to me, too. > > Martin, how long are you going to build official Windows binaries for > Python 2.7? > > Christian > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
2013/4/6 Gregory P. Smith : > I agree with Benjamin though is it really necessary to do two 2.7 releases a > year for the last two years? that's rather rapid (but as the release > manager its your call). What I like about 6 months is that its short enough, so we don't have feel bad about not taking a certain change; it can just be pushed to the next no-too-far-away release. A year is quite a while to wait for a fix to be released. It's also a nice timeframe for some distributions (looking at you, Ubuntu). -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
In article , Benjamin Peterson wrote: > 2013/4/6 Gregory P. Smith : > What I like about 6 months is that its short enough, so we don't have > feel bad about not taking a certain change; it can just be pushed to > the next no-too-far-away release. A year is quite a while to wait for > a fix to be released. It's also a nice timeframe for some > distributions (looking at you, Ubuntu). +1 to both a 6-month release interval and to soon announcing a date for the last maintenance release that is no later than 2015. As Georg points out, though, there undoubtedly will be pushback on that so we should make sure we have a good story for what happens after that date and we start communicating it in plenty of time. An important of that is emphasizing what will be available on Python 3.x by then and figuring out what to do about any important missing pieces, e.g. key third-party components not yet ported. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
On Apr 6, 2013, at 2:02 PM, Benjamin Peterson wrote: > we need to talk about how many more 2.7 releases there are > going to be. At the release of 2.7.0, I thought we promised 5 years of > bugfix maintenance, but my memory may be fuddled. I don't we need to make any "promises" beyond 5 years, but I also think it is likely the 2.7 will end-up being a long-term maintenance version of Python. At this year's Pycon keynote, I surveyed the crowd (approx 2500 people) and all almost everyone indicated that they had tried out Python 3.x and almost no one was using it in production or writing code for it. That indicates that Python 2.7 will continue to be important for a good while. In addition, the other implementations of Python (Jython, PyPy, GAE, and IronPython) are all at or nearly at Python 2.7. So, continued support will be needed for their users as well. After 2.7.4, I expect that the pace of real bug fixes will slow down, but that we'll continue to improve docs, add docstrings, update IDLE, etc. IMO, it is premature to utter the phrase "the end of 2.7". Better to say, "2.7 is stable and is expected to only have minor updates". Future point releases probably ought to occur "on their own schedule" whenever there are a sufficient number of changes to warrant a release, or an important security fix, or whenever the release managers have time. Raymond -- PYTHON 2.7 I'm not dead! CART DRIVER 'Ere. He says he's not dead. LARGE MAN Yes he is. PYTHON 2.7 I'm not! CART DRIVER He isn't. LARGE MAN He will be soon. He's very ill. PYTHON 2.7 I'm getting better! LARGE MAN You're not. You'll be stone dead in a few minutes. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
On 4/6/2013 5:11 PM, Georg Brandl wrote: Am 06.04.2013 23:02, schrieb Benjamin Peterson: Per my last message, 2.7.4 has at long last been released. I apologize for the long interval between 2.7.3 and 2.7.4. To create more determinism in the future, I will be soon updating PEP 373 with approximate dates of future 2.7 bugfix releases. I will be aiming for 6 month intervals. In 6 months, there will be a bunch more IDLE fixes (there are already some that were too late for today's releases), so that will be good from that standpoint. Some people will continue teaching with 2.7 for who knows how long. I expect Idle to be considerably polished within 2 years. This means we need to talk about how many more 2.7 releases there are going to be. At the release of 2.7.0, I thought we promised 5 years of bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0 was released in July 2010, which currently puts us within a few months of 3 years of maintenance. Over the past year, I've been happy to see a lot of movement towards 3 including the porting of important codebases like Twisted and Django. However, there's also no doubt that 2.x is still widely used. Obviously, there will be people who would be happy if we kept maintaining 2.7 until 2025, but I think at this juncture 5 total years of maintenance is reasonable. This means there will be approximately 4 more 2.7 releases. Thoughts? I agree that keeping to 5 years of official maintenance releases is reasonable at present. I do not remember if there was any promise of security fixes after 5 years. However, in 2015 I can well imagine offers from group(s) in the community to maintain the 2.7 branch with fixes ported from 3.x. I can imagine that. And I can imagine no volunteers ;-). I think that volunteering after the mid-2015 5-year release is too late in a sense. Anybody who thinks they will want to prolong maintenance should start working *now* to test bugfix patches on 2.7 and re-write as necessary and earn core-developer status. I think this should be suggested/publicized now. Unless Benjamin volunteers to continue doing releases, at least one new volunteer needs to learn how to do them, perhaps by working with him on some the the remaining releases he does do. At that point, we will have to decide how to treat releases from this "backports" branch. If there are at least a couple of people with 2.7 branch push privileges, who understand and agree to follow 'bugfixes only', with due consideration of back-compatibility, then I see no reason for such releases not to be official PSF releases. If some people take up 2.7 after the final 2.7 release and work independently us, then it is out of our hands. (And they will have to call their releases something other than 'Python 2.7.z') -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
On Sat, Apr 6, 2013 at 2:02 PM, Benjamin Peterson wrote: > juncture 5 total years of maintenance is reasonable. This means there > will be approximately 4 more 2.7 releases. That's good. From the subject of the email, I though you were announcing "This is the end of 2.7.x releases". 2 more year with 6 month cycle seem to be a good one. Thank you! Senthil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
On Sun, Apr 7, 2013 at 7:02 AM, Benjamin Peterson wrote: > Per my last message, 2.7.4 has at long last been released. I apologize > for the long interval between 2.7.3 and 2.7.4. To create more > determinism in the future, I will be soon updating PEP 373 with > approximate dates of future 2.7 bugfix releases. I will be aiming for > 6 month intervals. > > This means we need to talk about how many more 2.7 releases there are > going to be. At the release of 2.7.0, I thought we promised 5 years of > bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0 > was released in July 2010, which currently puts us within a few months > of 3 years of maintenance. Over the past year, I've been happy to see > a lot of movement towards 3 including the porting of important > codebases like Twisted and Django. However, there's also no doubt that > 2.x is still widely used. Obviously, there will be people who would be > happy if we kept maintaining 2.7 until 2025, but I think at this > juncture 5 total years of maintenance is reasonable. This means there > will be approximately 4 more 2.7 releases. > > Thoughts? This aligns well with what I've been telling people for the past couple of years, so +1 from me. Commercial Linux distros will also offer 2.7 support out beyond 2015, and it seems to me that the intersection between "needs Python 2.7 support beyond 2015" and "is willing to pay for that support" is likely to be pretty high. If the demand is there on the Windows side, then I expect companies like ActiveState and Enthought will also be happy to oblige. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
Quoting Benjamin Peterson : This means we need to talk about how many more 2.7 releases there are going to be. At the release of 2.7.0, I thought we promised 5 years of bugfix maintenance, but my memory may be fuddled. I'd like to promote the idea to abandon 2.7 bug fix releases earlier than that, e.g. along with the release of 3.4. My recollection is that "we" didn't actually promise any specific time frame; I recall that Guido said that Python 2.7 would be supported "indefinitely", which is not "infinitely" [1]. The Whats New says [2] """It’s very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions.""" which explicitly refuses to set a date. Of course, individual committers may have promised a more specific policy publicly in the past. Since Christian asked: I'll likely continue to make binary releases for Windows as along as Benjamin declares releases to be bug fix releases. However, it will become increasingly difficult for users to actually use these releases to build extension modules since Microsoft decided to take VS 2008 Express offline (VS 2008 remains available to MSDN subscribers; getting it from a store might also be difficult in 2014). I wonder whether the burden of maintaining three branches for bug fixes (2.7, 3.3, default) and three more for security fixes (2.6, 3.1, 3.2) is really sustainable for committers. I wouldn't want to back off wrt. security fixes, and 2.6 will soon fall out of the promised 5 years (after the initial release). However, stopping to accept bug fixes for 2.7 would IMO significantly reduce the load for committers - it would certainly continue to get security fixes, and (for the time being) "indefinitely" so. Wrt. to the 3.x migration rate: I think this is a self-fulfilling prophecy. Migration rate will certainly increase once we announce an end of 2.7, and then again when the end is actually reached. I'm doubtful with respect to a community-managed ongoing 2.7 bug fix release (i.e. I doubt that it will happen); the same was discussed for a next 2.x feature release, and it hasn't happened. OTOH, it is very likely that people will publish their own patches to 2.7 throughout the net, just as the Linux distributions already do. It may even happen that some volunteer offers to publish a combined repository for such patches, with various members of the community having write access to such a repository (but no formal releases coming out of that). Regards, Martin [1] http://mail.python.org/pipermail/python-dev/2009-November/093651.html [2] http://docs.python.org/dev/whatsnew/2.7.html#the-future-for-python-2-x ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
