Re: [Python-Dev] Future of 2.x.
On Thu, Jun 10, 2010 at 6:40 AM, Alexandre Vassalotti alexan...@peadrop.com wrote: On Wed, Jun 9, 2010 at 1:23 PM, Martin v. Löwis mar...@v.loewis.de wrote: Closing the backport requests is fine. For the feature requests, I'd only close them *after* the 2.7 release (after determining that they won't apply to 3.x, of course). There aren't that many backport requests, anyway, are there? There is only a few requests (about five) I get your point. It is the 'back-ports' that you have tagged. These were designed for 3.x and implemented in 3.x in the first place. I was concerned that there will be policy drawn or a practice that will close any/every existing Feature Request in Python 2.7. There are some cases (in stdlib) which can debated on the lines of feature request vs bug-fix and those will get hurt in the process. Thanks, Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Jun 10, 2010, at 09:01 AM, Steve Holden wrote: The current stumbling block isn't the language itself, it's the lack of support from third-party libraries. GSoC is addressing some of these issues, but so far we (the PSF, the dev community, anybody else except R. David Murray) haven't really come to grips with intractable problems like the broken state of the email package, and we are not doing well at attracting funds to support it. So I think we need to address a larger issue than just the language. As a development community we decided to change the language. Now we have to do what we can to ensure that the changed language has appropriate support. This is exactly my point - I totally agree. Let's take all that pent up energy and apply it to porting important libraries to Python 3. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On 6/10/2010 2:48 AM, Senthil Kumaran wrote: On Thu, Jun 10, 2010 at 6:40 AM, Alexandre Vassalotti alexan...@peadrop.com wrote: On Wed, Jun 9, 2010 at 1:23 PM, Martin v. Löwismar...@v.loewis.de wrote: Closing the backport requests is fine. For the feature requests, I'd only close them *after* the 2.7 release (after determining that they won't apply to 3.x, of course). There aren't that many backport requests, anyway, are there? There is only a few requests (about five) I get your point. It is the 'back-ports' that you have tagged. Right, things already in 3.x. These were designed for 3.x and implemented in 3.x in the first place. I was concerned that there will be policy drawn or a practice that will close any/every existing Feature Request in Python 2.7. There are some cases (in stdlib) which can debated on the lines of feature request vs bug-fix and those will get hurt in the process. I have started going through old open issues tagged with 2.5. Many are unclassified. Those that are feature requests that are *plausible* for 3.2 I am marking as such and retagging for 3.2, *not* closing. (I am also marking bug reports as such and asking the OP to test in 2.6/7 and maybe 3.1 if I cannot easily do so.) Ideally, all core/stdlib feature requests should be classified as such and tagged for 3.2 or even 3.3) only. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote: On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com wrote: it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. I disagree. If there are going to be features going into *any* post 2.7.0 version, there's no reason not to increment the revision number to 2.8, Since there's also a well-advertised decision that 2.7 will be the last 2.x, such a 2.8 isn't planned. But there's no reason to violate the no-features-in-bugfix-releases policy. We've seen violations cause trouble and confusion, but we've not seen it be successful. The policy wasn't arbitrary; let's stick to it. It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. Rationale: it's almost certain that if the existing Python core maintainers won't evolve Python 2.X past 2.7, some other group will, and losing existing context for that would kinda suck. - C ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Chris McDonough writes: It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. A keyword would do. Please don't add a status or something like that, though. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On 9 June 2010 07:26, Chris McDonough chr...@plope.com wrote: On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote: On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com wrote: it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. I disagree. If there are going to be features going into *any* post 2.7.0 version, there's no reason not to increment the revision number to 2.8, Since there's also a well-advertised decision that 2.7 will be the last 2.x, such a 2.8 isn't planned. But there's no reason to violate the no-features-in-bugfix-releases policy. We've seen violations cause trouble and confusion, but we've not seen it be successful. The policy wasn't arbitrary; let's stick to it. It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. Rationale: it's almost certain that if the existing Python core maintainers won't evolve Python 2.X past 2.7, some other group will, and losing existing context for that would kinda suck. Personally, as a user of Python, I'm already getting tired of the we won't let Python 2.x die arguments. Unless and until some other group comes along and says they definitely plan to pick up Python 2.x development (and set up or agree shared usage of all the relevant infrastructure, bug tracker, developers list, VCS, etc) I see the core developers' decision as made. 2.7 is the last Python 2.x release, and all further development will be on 3.x. On that basis I'm +1 on Alexandre's proposal. A 3rd party planning on working on a 2.8 release (not that I think such a party currently exists) can step up and extract the relevant tickets for their later reference if they feel the need. Let's not stop moving forward for the convenience of a hypothetical 2.8 development team. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 8:58 AM, Paul Moore p.f.mo...@gmail.com wrote: On that basis I'm +1 on Alexandre's proposal. A 3rd party planning on working on a 2.8 release (not that I think such a party currently exists) can step up and extract the relevant tickets for their later reference if they feel the need. Let's not stop moving forward for the convenience of a hypothetical 2.8 development team. Yes, closing the tickets as won't fix and tagging them as will-never-happen-in-2.x or something, is the best combination of both worlds: it will clean the tracker and ease further developments, and will allow anybody to pick up those tickets later. (I'm +1 too to Alexandre's proposal, btw) -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Paul Moore wrote: On 9 June 2010 07:26, Chris McDonough chr...@plope.com wrote: On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote: On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com wrote: it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. I disagree. If there are going to be features going into *any* post 2.7.0 version, there's no reason not to increment the revision number to 2.8, Since there's also a well-advertised decision that 2.7 will be the last 2.x, such a 2.8 isn't planned. But there's no reason to violate the no-features-in-bugfix-releases policy. We've seen violations cause trouble and confusion, but we've not seen it be successful. The policy wasn't arbitrary; let's stick to it. It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. Rationale: it's almost certain that if the existing Python core maintainers won't evolve Python 2.X past 2.7, some other group will, and losing existing context for that would kinda suck. Personally, as a user of Python, I'm already getting tired of the we won't let Python 2.x die arguments. Unless and until some other group comes along and says they definitely plan to pick up Python 2.x development (and set up or agree shared usage of all the relevant infrastructure, bug tracker, developers list, VCS, etc) I see the core developers' decision as made. 2.7 is the last Python 2.x release, and all further development will be on 3.x. On that basis I'm +1 on Alexandre's proposal. A 3rd party planning on working on a 2.8 release (not that I think such a party currently exists) can step up and extract the relevant tickets for their later reference if they feel the need. Let's not stop moving forward for the convenience of a hypothetical 2.8 development team. How does throwing away information represent moving forward? I have to say I am surprised by the current lack of momentum behind 3.x, but I do know users who consider that their current investment in the 2.x series is unlikely to migrate to 3.x in the next five years, and it would be strange if they didn't continue to develop 2.x (including backporting some 3.x features). I don't see why we have to make such work harder than it need be. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ All I want for my birthday is another birthday - Ian Dury, 1942-2000 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On 09/06/2010 13:56, Steve Holden wrote: Paul Moore wrote: On 9 June 2010 07:26, Chris McDonoughchr...@plope.com wrote: On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote: On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaranorsent...@gmail.com wrote: it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. I disagree. If there are going to be features going into *any* post 2.7.0 version, there's no reason not to increment the revision number to 2.8, Since there's also a well-advertised decision that 2.7 will be the last 2.x, such a 2.8 isn't planned. But there's no reason to violate the no-features-in-bugfix-releases policy. We've seen violations cause trouble and confusion, but we've not seen it be successful. The policy wasn't arbitrary; let's stick to it. It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. Rationale: it's almost certain that if the existing Python core maintainers won't evolve Python 2.X past 2.7, some other group will, and losing existing context for that would kinda suck. Personally, as a user of Python, I'm already getting tired of the we won't let Python 2.x die arguments. Unless and until some other group comes along and says they definitely plan to pick up Python 2.x development (and set up or agree shared usage of all the relevant infrastructure, bug tracker, developers list, VCS, etc) I see the core developers' decision as made. 2.7 is the last Python 2.x release, and all further development will be on 3.x. On that basis I'm +1 on Alexandre's proposal. A 3rd party planning on working on a 2.8 release (not that I think such a party currently exists) can step up and extract the relevant tickets for their later reference if they feel the need. Let's not stop moving forward for the convenience of a hypothetical 2.8 development team. How does throwing away information represent moving forward? I'm inclined to agree. There is no *need* to close these tickets now. I have to say I am surprised by the current lack of momentum behind 3.x, but I do know users who consider that their current investment in the 2.x series is unlikely to migrate to 3.x in the next five years, and it would be strange if they didn't continue to develop 2.x (including backporting some 3.x features). Who is the 'they' in your last sentence here? It seems to imply the 'users'... Certainly no-one specific (neither individual nor group) have stepped up and said they will continue to develop Python 2.x. Even if they did it is not clear that they would use the python.org infrastructure to do it. The Python core developers (basically) *have* moved on and are unlikely to further develop 2.x. We'll see though, it's all speculation at the moment. All the best, Michael I don't see why we have to make such work harder than it need be. regards Steve -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Jun 09, 2010, at 01:15 AM, Fred Drake wrote: On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com wrote: it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. I disagree. If there are going to be features going into *any* post 2.7.0 version, there's no reason not to increment the revision number to 2.8, Since there's also a well-advertised decision that 2.7 will be the last 2.x, such a 2.8 isn't planned. But there's no reason to violate the no-features-in-bugfix-releases policy. We've seen violations cause trouble and confusion, but we've not seen it be successful. The policy wasn't arbitrary; let's stick to it. I completely agree with Fred. New features in point releases will cause many more headaches than opening up a 2.8, which I still hope we don't do. I'd rather see all that pent up energy focussed on doing whatever we can to help people transition to Python 3. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Michael Foord wrote: How does throwing away information represent moving forward? I'm inclined to agree. There is no *need* to close these tickets now. I have to say I am surprised by the current lack of momentum behind 3.x, but I do know users who consider that their current investment in the 2.x series is unlikely to migrate to 3.x in the next five years, and it would be strange if they didn't continue to develop 2.x (including backporting some 3.x features). Who is the 'they' in your last sentence here? It seems to imply the 'users'... Certainly no-one specific (neither individual nor group) have stepped up and said they will continue to develop Python 2.x. Even if they did it is not clear that they would use the python.org infrastructure to do it. The Python core developers (basically) *have* moved on and are unlikely to further develop 2.x. We'll see though, it's all speculation at the moment. I think it also depends on which core developers you ask :-) Many of them are not keen on having to maintain Python2 for much longer, but some of them may have assets codified in Python2 or interests based Python2 that they'll want to keep for more than just another 5 years. E.g. we still have customers that are on Python 2.3 and have just recently considered moving to Python 2.5. Depending on where you look, motivations are rather diverse. It's certainly not fair to require all core developers to continue working on Python2, but it would also be unfair to cancel out that possibility for a subset of interested devs. Even more so, since it doesn't really create any extra work for those that have no interest. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 09 2010) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK39 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Jun 09, 2010, at 04:42 PM, M.-A. Lemburg wrote: Many of them are not keen on having to maintain Python2 for much longer, but some of them may have assets codified in Python2 or interests based Python2 that they'll want to keep for more than just another 5 years. E.g. we still have customers that are on Python 2.3 and have just recently considered moving to Python 2.5. Depending on where you look, motivations are rather diverse. It's certainly not fair to require all core developers to continue working on Python2, but it would also be unfair to cancel out that possibility for a subset of interested devs. Even more so, since it doesn't really create any extra work for those that have no interest. Note that Python 2.7 will be *maintained* for a very long time, which should satisfy those folks who still require Python 2. Anybody on older (and currently unmaintained) versions of Python 2 will not care about new features so a Python 2.8 wouldn't help them anyway. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Barry Warsaw ba...@python.org wrote: On Jun 09, 2010, at 04:42 PM, M.-A. Lemburg wrote: Many of them are not keen on having to maintain Python2 for much longer, but some of them may have assets codified in Python2 or interests based Python2 that they'll want to keep for more than just another 5 years. E.g. we still have customers that are on Python 2.3 and have just recently considered moving to Python 2.5. Depending on where you look, motivations are rather diverse. It's certainly not fair to require all core developers to continue working on Python2, but it would also be unfair to cancel out that possibility for a subset of interested devs. Even more so, since it doesn't really create any extra work for those that have no interest. Note that Python 2.7 will be *maintained* for a very long time, which should satisfy those folks who still require Python 2. Anybody on older (and currently unmaintained) versions of Python 2 will not care about new features so a Python 2.8 wouldn't help them anyway. There are two kinds of new features, though. Those added to improve (or at any rate modify :-) the product, and those added to keep the product relevant to a changing external world (new operating systems, new communication protocols, etc.) I think it would take a pretty strong crystal ball to be able to rule out the latter kind of feature add from the 2.x line. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Jun 09, 2010, at 09:13 AM, Bill Janssen wrote: Barry Warsaw ba...@python.org wrote: Note that Python 2.7 will be *maintained* for a very long time, which should satisfy those folks who still require Python 2. Anybody on older (and currently unmaintained) versions of Python 2 will not care about new features so a Python 2.8 wouldn't help them anyway. There are two kinds of new features, though. Those added to improve (or at any rate modify :-) the product, and those added to keep the product relevant to a changing external world (new operating systems, new communication protocols, etc.) I think it would take a pretty strong crystal ball to be able to rule out the latter kind of feature add from the 2.x line. The latter should mostly be supported by third party packages available in the Cheeseshop. To the extent that such support can't be effected by add-ons (e.g. new OS support), I think a better approach would be to encourage and allow unofficial ports by utilizing dvcs branches (we *are* moving to Mercurial after Python 2.7 final is released, right?). I think we should plan on 2.7 being the last Python 2, and spend lots of effort to get people onto Python 3, partially by offering big carrots like Unladen Swallow, a better/no GIL, etc. I think it should be part of the PSF's mission to help that happen through directed sponsorship, sprints, and other tools. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 12:32 PM, Barry Warsaw ba...@python.org wrote: On Jun 09, 2010, at 09:13 AM, Bill Janssen wrote: Barry Warsaw ba...@python.org wrote: Note that Python 2.7 will be *maintained* for a very long time, which should satisfy those folks who still require Python 2. Anybody on older (and currently unmaintained) versions of Python 2 will not care about new features so a Python 2.8 wouldn't help them anyway. There are two kinds of new features, though. Those added to improve (or at any rate modify :-) the product, and those added to keep the product relevant to a changing external world (new operating systems, new communication protocols, etc.) I think it would take a pretty strong crystal ball to be able to rule out the latter kind of feature add from the 2.x line. The latter should mostly be supported by third party packages available in the Cheeseshop. To the extent that such support can't be effected by add-ons (e.g. new OS support), I think a better approach would be to encourage and allow unofficial ports by utilizing dvcs branches (we *are* moving to Mercurial after Python 2.7 final is released, right?). I think we should plan on 2.7 being the last Python 2, and spend lots of effort to get people onto Python 3, partially by offering big carrots like Unladen Swallow, a better/no GIL, etc. I think it should be part of the PSF's mission to help that happen through directed sponsorship, sprints, and other tools. -Barry +1 fearless FLUFL ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 08:12, Barry Warsaw ba...@python.org wrote: On Jun 09, 2010, at 04:42 PM, M.-A. Lemburg wrote: Many of them are not keen on having to maintain Python2 for much longer, but some of them may have assets codified in Python2 or interests based Python2 that they'll want to keep for more than just another 5 years. E.g. we still have customers that are on Python 2.3 and have just recently considered moving to Python 2.5. Depending on where you look, motivations are rather diverse. It's certainly not fair to require all core developers to continue working on Python2, but it would also be unfair to cancel out that possibility for a subset of interested devs. Even more so, since it doesn't really create any extra work for those that have no interest. Note that Python 2.7 will be *maintained* for a very long time, which should satisfy those folks who still require Python 2. Anybody on older (and currently unmaintained) versions of Python 2 will not care about new features so a Python 2.8 wouldn't help them anyway. The other point about Alexandre's desire to close the issues is that nothing is really getting deleted; closed issues can still be searched for. Alexandre simply wants to not waste anyone's time who happens to be looking at the tracker with issues that the core team will simply never work on. If some mythical 2.8 fork of Python comes along they can perform a search and find the issues that were closed because they were backports that never happened. So +1 on closing them out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Jun 8, 2010, at 9:13 PM, Benjamin Peterson wrote: 2010/6/8 Alexandre Vassalotti alexan...@peadrop.com: Is there is any plan for a 2.8 release? If not, I will go through the tracker and close outstanding backport requests of 3.x features to 2.x. Not from the core development team. The current plan is to make 2.7 the last 2.x release. The theory is that this will encourage people to switch to 3.x. In practice, the users will get a say in this and time will tell. When I do polls at conferences, it seems that most participants have briefly tried 3.x but are continuing to develop in 2.x. Raymond___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On 6/9/2010 4:07 AM, Stephen J. Turnbull wrote: Chris McDonough writes: It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. Closed issues are not lost. They can still be searched and the result downloaded. A keyword would do. Please don't add a status or something like that, though. I believe Type: feature request; Version: 2.7; Resolution wont fix should do fine now. I believe Alexander will use the first two to find things to close. Anything else anyone finds could be made to match. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On 6/9/2010 10:42 AM, M.-A. Lemburg wrote: Steve Holden wrote How does throwing away information represent moving forward? 'Closing' a tracker issue does not 'throw away' information', it *adds* information as to current intention. It's certainly not fair to require all core developers to continue working on Python2, but it would also be unfair to cancel out that possibility for a subset of interested devs. Closing a set of issues does not cancel out that possibility. If such a subset of devs develops, they can easily reopen (or move) particular issues they are interested in working on. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On 6/9/2010 4:07 AM, Stephen J. Turnbull wrote: Closed issues are not lost. They can still be searched and the result downloaded. A keyword would do. Please don't add a status or something like that, though. I believe Type: feature request; Version: 2.7; Resolution wont fix should do fine now. I believe Alexander will use the first two to find things to close. Anything else anyone finds could be made to match. Are there any currently existing issues that match that criteria (feature request, 2.7, won't fix)? I don't have good connectivity here so I can't check. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 12:40, Eric Smith e...@trueblade.com wrote: On 6/9/2010 4:07 AM, Stephen J. Turnbull wrote: Closed issues are not lost. They can still be searched and the result downloaded. A keyword would do. Please don't add a status or something like that, though. I believe Type: feature request; Version: 2.7; Resolution wont fix should do fine now. I believe Alexander will use the first two to find things to close. Anything else anyone finds could be made to match. Are there any currently existing issues that match that criteria (feature request, 2.7, won't fix)? 2.7, closed, wont fix has 27 issues at the moment, which is obviously small and easy to peruse. -Brett I don't have good connectivity here so I can't check. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. Rationale: it's almost certain that if the existing Python core maintainers won't evolve Python 2.X past 2.7, some other group will, and losing existing context for that would kinda suck. Roundup keeps track of all status changes, see the bottom of an arbitrary issue for an example. So I don't think any additional recording is necessary. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Am 09.06.2010 05:58, schrieb Alexandre Vassalotti: Is there is any plan for a 2.8 release? If not, I will go through the tracker and close outstanding backport requests of 3.x features to 2.x. Closing the backport requests is fine. For the feature requests, I'd only close them *after* the 2.7 release (after determining that they won't apply to 3.x, of course). There aren't that many backport requests, anyway, are there? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Barry Warsaw wrote: On Jun 09, 2010, at 09:13 AM, Bill Janssen wrote: Barry Warsaw ba...@python.org wrote: Note that Python 2.7 will be *maintained* for a very long time, which should satisfy those folks who still require Python 2. Anybody on older (and currently unmaintained) versions of Python 2 will not care about new features so a Python 2.8 wouldn't help them anyway. There are two kinds of new features, though. Those added to improve (or at any rate modify :-) the product, and those added to keep the product relevant to a changing external world (new operating systems, new communication protocols, etc.) I think it would take a pretty strong crystal ball to be able to rule out the latter kind of feature add from the 2.x line. The latter should mostly be supported by third party packages available in the Cheeseshop. To the extent that such support can't be effected by add-ons (e.g. new OS support), I think a better approach would be to encourage and allow unofficial ports by utilizing dvcs branches (we *are* moving to Mercurial after Python 2.7 final is released, right?). I think we should plan on 2.7 being the last Python 2, and spend lots of effort to get people onto Python 3, partially by offering big carrots like Unladen Swallow, a better/no GIL, etc. I think it should be part of the PSF's mission to help that happen through directed sponsorship, sprints, and other tools. The current stumbling block isn't the language itself, it's the lack of support from third-party libraries. GSoC is addressing some of these issues, but so far we (the PSF, the dev community, anybody else except R. David Murray) haven't really come to grips with intractable problems like the broken state of the email package, and we are not doing well at attracting funds to support it. So I think we need to address a larger issue than just the language. As a development community we decided to change the language. Now we have to do what we can to ensure that the changed language has appropriate support. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ All I want for my birthday is another birthday - Ian Dury, 1942-2000 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Terry Reedy wrote: On 6/9/2010 10:42 AM, M.-A. Lemburg wrote: Steve Holden wrote How does throwing away information represent moving forward? 'Closing' a tracker issue does not 'throw away' information', it *adds* information as to current intention. It's certainly not fair to require all core developers to continue working on Python2, but it would also be unfair to cancel out that possibility for a subset of interested devs. Closing a set of issues does not cancel out that possibility. If such a subset of devs develops, they can easily reopen (or move) particular issues they are interested in working on. As long as that's the case I am fine with the change. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ All I want for my birthday is another birthday - Ian Dury, 1942-2000 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Barry Warsaw wrote: On Jun 09, 2010, at 01:15 AM, Fred Drake wrote: On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com wrote: it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. I disagree. If there are going to be features going into *any* post 2.7.0 version, there's no reason not to increment the revision number to 2.8, Since there's also a well-advertised decision that 2.7 will be the last 2.x, such a 2.8 isn't planned. But there's no reason to violate the no-features-in-bugfix-releases policy. We've seen violations cause trouble and confusion, but we've not seen it be successful. The policy wasn't arbitrary; let's stick to it. I completely agree with Fred. New features in point releases will cause many more headaches than opening up a 2.8, which I still hope we don't do. I'd rather see all that pent up energy focussed on doing whatever we can to help people transition to Python 3. Though one might ironically suggest that sticking to the policy actually represents a change in policy :) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ All I want for my birthday is another birthday - Ian Dury, 1942-2000 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 1:23 PM, Martin v. Löwis mar...@v.loewis.de wrote: Closing the backport requests is fine. For the feature requests, I'd only close them *after* the 2.7 release (after determining that they won't apply to 3.x, of course). There aren't that many backport requests, anyway, are there? There is only a few requests (about five). -- Alexandre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 5:55 AM, Facundo Batista facundobati...@gmail.com wrote: Yes, closing the tickets as won't fix and tagging them as will-never-happen-in-2.x or something, is the best combination of both worlds: it will clean the tracker and ease further developments, and will allow anybody to pick up those tickets later. The issue I care about are already tagged as 26backport. So, I don't think another keyword is needed. -- Alexandre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 9:28 AM, Alexandre Vassalotti alexan...@peadrop.com wrote: Is there is any plan for a 2.8 release? If not, I will go through the tracker and close outstanding backport requests of 3.x features to You mean, simply mark them as Wont-Fix and close. I doubt, if this is desirable action to take. Even thought they are new features, it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. This is just my opinion. -- Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com wrote: it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. I disagree. If there are going to be features going into *any* post 2.7.0 version, there's no reason not to increment the revision number to 2.8, Since there's also a well-advertised decision that 2.7 will be the last 2.x, such a 2.8 isn't planned. But there's no reason to violate the no-features-in-bugfix-releases policy. We've seen violations cause trouble and confusion, but we've not seen it be successful. The policy wasn't arbitrary; let's stick to it. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
