Status of 2.7 and 3.2
2.7 Once upon a time, the plan was to come out with 2.6 and 3.0, and then after the usual interval, 2.7 and 3.1. As it turned out, 3.0 came out 3 months after 2.6, but, as it typical of x.0 releases, had some flaws leading to 3.1 now just 6 month later. I have thought that 2.7 was now to come out instead with 3.2 and would include backported 3.2 new features. Others expect 2.7 to come out soon after 3.1 and to only contain new 3.1 features. So Guido or someone, please clarify: is 2.7 to be the counterpart of 3.1 or 3.2? Data: On the tracker, new features are being assigned to 2.7 and 3.2. PEP 373 Python 2.7 Release Schedule says zilch: Release Schedule: Not yet finalized Possible features for 2.7: Nothing here 3.2 At some point, 3.x will become the "trunk" branch. It seems to me that this should be done with 3.2 as part of the transition to Mercurial. A. As long as 2.x is 'trunk', some people will view 3.x as 'experimental'. That was true for 3.0, but (much?) less so for 3.1. Is there any known reason why 3.2 should not soon be considered and treated as the main development version, to become the main production version? B. All new features will go into 3.2. Only some will be backported to 2.x. So it seems that the flow should be to develop for 3.2 and maybe backport thereafter. 2.final Is there any thought of making 2.7 be 2.final? A. To my mind, the main reason to add features to 2.x is to make transition to 3.x easier, rather than to discourage transition to 3.x. B. Do we really want to encourage library developers to put their 'upgrade to a new version' energy into 2.x to 2.x+1 upgrades, rather than a 2.x to 3.y upgrades? C. Some people are sticking with some version of 2.x because they want a stable version with minimal disturbance. Such people might have preferred, for instance, getting 2.5.5 in April instead of the latest 2.6 release. Instead people 2.5 fixes are being told "Sorry. 2.5 is out of Maintenance phase and into SecurityFix only phase." Once 2.x is put in feature freeze, micro bugfix releases can appear for years, as long as bugs are found and patches submitted and committed. It should gradually become truly rock solid. Terry Jan Reedy
I have thought that 2.7 was now to come out instead with 3.2 and would include backported 3.2 new features. Others expect 2.7 to come out soon after 3.1 and to only contain new 3.1 features. So Guido or someone, please clarify: is 2.7 to be the counterpart of 3.1 or 3.2?
Neither, nor. 2.7 will be released 18..24 months after 2.6, i.e. between April 2010 and October 2010. I think it's too early to speculate about a release schedule for 3.2.
3.2
At some point, 3.x will become the "trunk" branch. It seems to me that this should be done with 3.2 as part of the transition to Mercurial.
I'm not sure that the concept of a "trunk" branch still exists in Mercurial. PEP 385 apparently doesn't have resolved the branch strategy for Mercurial yet. With cloned branches, I think the concept of a "trunk" becomes irrelevant.
A. As long as 2.x is 'trunk', some people will view 3.x as 'experimental'. That was true for 3.0, but (much?) less so for 3.1. Is there any known reason why 3.2 should not soon be considered and treated as the main development version, to become the main production version?
B. All new features will go into 3.2. Only some will be backported to 2.x. So it seems that the flow should be to develop for 3.2 and maybe backport thereafter.
What about bug fixes? How will they flow?
2.final
Is there any thought of making 2.7 be 2.final?
Yes. Whether or not a 2.8 release will happen hasn't been decided yet, but 2.7 may well be the last 2.x release.
B. Do we really want to encourage library developers to put their 'upgrade to a new version' energy into 2.x to 2.x+1 upgrades, rather than a 2.x to 3.y upgrades?
IMO, it's much up to the contributors. If the regular committers want to continue to work on 2.x, and a release manager is found to create releases, we can continue to release 2.8, and perhaps 2.9. However, I think at this point, it is too early to discuss that - 2.7 is still many months ahead. Regards, Martin
"Martin v. Löwis" writes:
I'm not sure that the concept of a "trunk" branch still exists in Mercurial. PEP 385 apparently doesn't have resolved the branch strategy for Mercurial yet. With cloned branches, I think the concept of a "trunk" becomes irrelevant.
"Trunk" exists as a technical restriction in CVS, and maybe to some extent in Subversion. Of course that restriction is lifted by DVCSes. But really "trunk" is a social concept. Most projects have a trunk. Even the anarchy known as GNU Arch converged on Tom Lord's version, just as the storm of turbulance known as "Linux kernel development" does on Linus's. Python's 2.x/py3k division is a tour de force; I still can't believe my eyes that you've pulled it off. Consider Perl 6, LaTeX 3, and Zope 3, or Linux 3, for that matter. The first 3 are all facing the "what is trunk?" issue, in the case of Zope several years after the "point oh" release, and AFAIK there are no current plans for Linux 3 (a microkernel architecture, maybe?<1.01 wink>). Of course the issues faced by LaTeX, Zope, and the kernel are quite different from Python's, and I don't know enough about Perl internals to compare. So I think "trunk" does matter. But it's not entirely in the power of the Python committers, not even the BDFL, to determine what "trunk" is.
Terry Reedy writes:
A. As long as 2.x is 'trunk', some people will view 3.x as 'experimental'. That was true for 3.0, but (much?) less so for 3.1. Is there any known reason why 3.2 should not soon be considered and treated as the main development version, to become the main production version?
Yes. User/developers may prefer strongly prefer the stability of 2.x. That's the problem of being a successful product, you lose agility almost by definition.
B. All new features will go into 3.2. Only some will be backported to 2.x. So it seems that the flow should be to develop for 3.2 and maybe backport thereafter.
What about bug fixes? How will they flow?
This has to be ad hoc, at least at first. Some bugs will be uncovered in each version. The solutions will often not be the same in the different versions. Many developers will be downstream, and only willing to contribute the patch for the version they use.
B. Do we really want to encourage library developers to put their 'upgrade to a new version' energy into 2.x to 2.x+1 upgrades, rather than a 2.x to 3.y upgrades?
IMO, it's much up to the contributors.
I think so, too. Terry's word "encourage" is appropriate here, though, and at some point that question will need to be answered. I think he's right to raise it early.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen J. Turnbull wrote:
"Martin v. Löwis" writes:
I'm not sure that the concept of a "trunk" branch still exists in Mercurial. PEP 385 apparently doesn't have resolved the branch strategy for Mercurial yet. With cloned branches, I think the concept of a "trunk" becomes irrelevant.
"Trunk" exists as a technical restriction in CVS, and maybe to some extent in Subversion. Of course that restriction is lifted by DVCSes.
But really "trunk" is a social concept. Most projects have a trunk. Even the anarchy known as GNU Arch converged on Tom Lord's version, just as the storm of turbulance known as "Linux kernel development" does on Linus's.
Python's 2.x/py3k division is a tour de force; I still can't believe my eyes that you've pulled it off. Consider Perl 6, LaTeX 3, and Zope 3, or Linux 3, for that matter. The first 3 are all facing the "what is trunk?" issue, in the case of Zope several years after the "point oh" release, and AFAIK there are no current plans for Linux 3 (a microkernel architecture, maybe?<1.01 wink>). Of course the issues faced by LaTeX, Zope, and the kernel are quite different from Python's, and I don't know enough about Perl internals to compare.
FWIW, it seems to be consensus in the Zope community that "Zope3" was a misnomer, reflecting a vision for the software (serving as the replacement / successor to Zope2) which it didn't grow to fulfill. At this point, the "reusable" bits now form a collection of separately-released packages referred to as the "Zope Toolkit,"[1] which is intended to be used by Zope2, Grok, and the folks still running the "pure" Zope3 appserver. A lot of the work involved in this effort has been in disentagling the dependencies among the various packages, precisely so that they can be used piecemeal, without pulling in all of the stack. [1] http://docs.zope.org/zopetoolkit/ Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKK7px+gerLs4ltQ4RAoMnAJ9WTL8zo3+bSop+SAXr+akp85tMZQCfS5oC y14j64VJPjgxDQzCb1p/iZo= =RCZa -----END PGP SIGNATURE-----
2009/6/7 Stephen J. Turnbull <stephen@xemacs.org>:
Python's 2.x/py3k division is a tour de force; I still can't believe my eyes that you've pulled it off.
Well, It's not pulled off until Python 3 has surpassed Python 2 in usage. That's still a long way away. I'm not familiar with the other examples except Zope 3, which is a completely different thing, so it may very well be that Python did it way better. But still, it's not pulled off yet. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro writes:
2009/6/7 Stephen J. Turnbull <stephen@xemacs.org>:
Python's 2.x/py3k division is a tour de force; I still can't believe my eyes that you've pulled it off.
Well, It's not pulled off until Python 3 has surpassed Python 2 in usage.
I'm referring only to the management of the dual-trunk workflow, not to whether Python3 will be the preferred path for the future. That workflow has its problems, but still it seems very successful in keeping what needs to be synced, synced, and what needs to be different, different.
Martin v. Löwis wrote:
I have thought that 2.7 was now to come out instead with 3.2 and would include backported 3.2 new features. Others expect 2.7 to come out soon after 3.1 and to only contain new 3.1 features. So Guido or someone, please clarify: is 2.7 to be the counterpart of 3.1 or 3.2?
Neither, nor. 2.7 will be released 18..24 months after 2.6, i.e. between April 2010 and October 2010. I think it's too early to speculate about a release schedule for 3.2.
I think Terry's underlying question is more basic than that. It can also be phrased as: "Is 2.7 allowed to have new features which did not appear in 3.1?" In previous discussions, a general policy has been articulated that having released Python 3.0, any new features should appear in a 3.x release before they appear in a 2.x release. Following that policy (which I think is actually a good one) means there are certain consequences for the two possible answers to the above question: A. "No." This answer means that 2.7 will only contain new features that are part of 3.1. If 2.7 sticks to a normal 18-24 month release cycle the only activities on the trunk for the next 12 months or so should be backports from 3.1 and bug fixes. New features added to the py3k branch for 3.2 should not be backported until after 2.7 is released. The other alternative in this case is to release 2.7 earlier than normal, but that creates problems in terms of the absolute duration of maintenance branch support for 2.6. B. "Yes." This answer means that the 3.1 to 3.2 development cycle will need to be truncated by roughly 6 months so that 3.2 can be released before 2.7 with any new features of interest. The 3.2 and 2.7 releases should then occur within a few months of each other. Releasing 2.7 early doesn't seem like a good idea to me and neither does putting the trunk into the equivalent of a feature freeze for 12 months or more. So I'm in favour of the idea of a paired 3.2/2.7 release late next year. I don't think that's a novel idea though - I'm pretty sure it was suggested (and met with general approval) when the idea of a short release cycle for 3.1 was first brought up. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
Martin v. Löwis wrote:
I have thought that 2.7 was now to come out instead with 3.2 and would include backported 3.2 new features. Others expect 2.7 to come out soon after 3.1 and to only contain new 3.1 features. So Guido or someone, please clarify: is 2.7 to be the counterpart of 3.1 or 3.2? Neither, nor. 2.7 will be released 18..24 months after 2.6, i.e. between April 2010 and October 2010. I think it's too early to speculate about a release schedule for 3.2.
I think Terry's underlying question is more basic than that. It can also be phrased as:
"Is 2.7 allowed to have new features which did not appear in 3.1?"
I don't think this is the question Terry meant to ask, and the answer to this question is a clear "Certainly, but you are asking the wrong question." The question that Terry really meant to ask is "why is there no release candidate for 2.7 already, when 3.1 is going to be released RSN?", and that question arises from the (incorrect) understanding that 2.x releases and 3.x releases will be lock-step. The question that you posed should have been phrased as "Is 2.7 allowed to have new features which don't also appear on the 3k branch?", to which the answer is a clear "No."
In previous discussions, a general policy has been articulated that having released Python 3.0, any new features should appear in a 3.x release before they appear in a 2.x release.
I don't think that the policy has been articulated in exactly that way, and it certainly wasn't implemented for 2.6/3.0. 2.6 was released with features that had not been released in any 3.x release, just because 3.x had not been released at all.
A. "No."
This answer means that 2.7 will only contain new features that are part of 3.1. If 2.7 sticks to a normal 18-24 month release cycle the only activities on the trunk for the next 12 months or so should be backports from 3.1 and bug fixes. New features added to the py3k branch for 3.2 should not be backported until after 2.7 is released. The other alternative in this case is to release 2.7 earlier than normal, but that creates problems in terms of the absolute duration of maintenance branch support for 2.6.
I think this makes it clear that the answer can't possibly be "No". Not allowing addition of new features even though the release is still 12 months away would be unreasonable, IMO - what's the point of freezing development now, and where should new features to 2.x be added if not to the trunk? Likewise, releasing 2.7 now is completely unacceptable.
B. "Yes."
This answer means that the 3.1 to 3.2 development cycle will need to be truncated by roughly 6 months so that 3.2 can be released before 2.7 with any new features of interest. The 3.2 and 2.7 releases should then occur within a few months of each other.
Assuming the policy "release new features for 2.x only after they got released for 3.x". I don't think such a policy actually exists. Regards, Martin
On Sun, 7 Jun 2009 at 18:55, "Martin v. L�wis" wrote:
B. "Yes."
This answer means that the 3.1 to 3.2 development cycle will need to be truncated by roughly 6 months so that 3.2 can be released before 2.7 with any new features of interest. The 3.2 and 2.7 releases should then occur within a few months of each other.
Assuming the policy "release new features for 2.x only after they got released for 3.x". I don't think such a policy actually exists.
I'm neutral on time frames, but I think that it _should_ be a policy that new features only get released to the 2.x branch after they have been released in the 3.x branch. Or, rather, I though that policy was implicit in the idea that we weren't _automatically_ backporting features, specifically in order to encourage 3.x adoption. So if 2.7 is going to come out before 3.2, you'll have to convince me that having new features in 2.7 that aren't in 3.1 is a good idea :) Note that I'm not advocating feature freezing the trunk, but rather having 3.2 come out before or in sync with 2.7. --David
I'm neutral on time frames, but I think that it _should_ be a policy that new features only get released to the 2.x branch after they have been released in the 3.x branch. Or, rather, I though that policy was implicit in the idea that we weren't _automatically_ backporting features, specifically in order to encourage 3.x adoption.
I think "backporting" is an entirely different issue, let alone "automatic" backporting. What *is* policy (AFAIU) is "any feature in the trunk must also exist in the py3k branch". IMO, this is sufficient to encourage 3.x adoption, and it is a policy that is silent wrt. to release date ordering. By the policy you propose, we could not have released 2.6 in October 2008, which we really really wanted to because Apple wanted us to.
So if 2.7 is going to come out before 3.2, you'll have to convince me that having new features in 2.7 that aren't in 3.1 is a good idea :)
I don't see why the precise ordering of release dates matters at all. It seems you are happy with having 3.2 be released "around the same time" as 2.7. What is "the same time"? 3 months difference? 6 months difference? It certainly wouldn't be a year. Regards, Martin
On Sun, 7 Jun 2009 at 21:21, "Martin v. L�wis" wrote:
I'm neutral on time frames, but I think that it _should_ be a policy that new features only get released to the 2.x branch after they have been released in the 3.x branch. Or, rather, I though that policy was implicit in the idea that we weren't _automatically_ backporting features, specifically in order to encourage 3.x adoption.
I think "backporting" is an entirely different issue, let alone "automatic" backporting.
What *is* policy (AFAIU) is "any feature in the trunk must also exist in the py3k branch". IMO, this is sufficient to encourage 3.x adoption, and it is a policy that is silent wrt. to release date ordering.
You are right, my use of the term backport was imprecise. My impression at pycon was that Guido (and others) wanted a stronger policy than "make sure new features in trunk are also in 3.x". I heard this as "put new features in 3.x, not 2.x, to encourage 3.x adoption," but leaving the decision to the individual developers on whether or not to also "backport" them to 2.x. (The quotes around backport being that if you know you are going to put it into both it is currently easier to do trunk first.) As we have discovered since, this tends to get modified by wanting to ease transition from 2.x to 3.x by providing some of the features in 2.x (I'm thinking specifically of the distutils discussion.) How I got from that to release date ordering was by hearing that as "new features should be in 3.x first, and only maybe in 2.x". Clearly that was just my interpretation :)
By the policy you propose, we could not have released 2.6 in October 2008, which we really really wanted to because Apple wanted us to.
I don't think the 2.6 release date is relevant to this discussion, since 3.x hadn't been released at all at that point. What I want to avoid is people writing new code for 2.7 instead of 3.1 because they want to take advantage of a nifty new feature that 3.1 doesn't have.
So if 2.7 is going to come out before 3.2, you'll have to convince me that having new features in 2.7 that aren't in 3.1 is a good idea :)
I don't see why the precise ordering of release dates matters at all. It seems you are happy with having 3.2 be released "around the same time" as 2.7. What is "the same time"? 3 months difference? 6 months difference? It certainly wouldn't be a year.
No more than three months, I'd say, but that's just a gut level feeling, not backed by a specific argument. That said, I also have a gut level feeling that it is better to have the new features come out in 3.2 _first_. But I'm not presenting that as anything more than my feeling, and I'm happy to go with whatever consensus develops. FWIW, Benjamin has said the he personally has no problem with 3.2's release cycle being shorter than "normal". --David
R. David Murray wrote:
[snip...]
By the policy you propose, we could not have released 2.6 in October 2008, which we really really wanted to because Apple wanted us to.
I don't think the 2.6 release date is relevant to this discussion, since 3.x hadn't been released at all at that point. What I want to avoid is people writing new code for 2.7 instead of 3.1 because they want to take advantage of a nifty new feature that 3.1 doesn't have.
But 3.1 is in feature freeze (py3k trunk) and it is not possible to check-in code for 3.2. Following this policy it would mean a feature freeze on trunk for an indefinite period of time. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
2009/6/7 Michael Foord <fuzzyman@voidspace.org.uk>:
R. David Murray wrote:
[snip...]
By the policy you propose, we could not have released 2.6 in October 2008, which we really really wanted to because Apple wanted us to.
I don't think the 2.6 release date is relevant to this discussion, since 3.x hadn't been released at all at that point. What I want to avoid is people writing new code for 2.7 instead of 3.1 because they want to take advantage of a nifty new feature that 3.1 doesn't have.
But 3.1 is in feature freeze (py3k trunk) and it is not possible to check-in code for 3.2. Following this policy it would mean a feature freeze on trunk for an indefinite period of time.
And that's what we want to avoid, so we are discussing 3.2. -- Regards, Benjamin
On Sun, 7 Jun 2009 at 21:55, Michael Foord wrote:
R. David Murray wrote:
[snip...]
By the policy you propose, we could not have released 2.6 in October 2008, which we really really wanted to because Apple wanted us to.
I don't think the 2.6 release date is relevant to this discussion, since 3.x hadn't been released at all at that point. What I want to avoid is people writing new code for 2.7 instead of 3.1 because they want to take advantage of a nifty new feature that 3.1 doesn't have.
But 3.1 is in feature freeze (py3k trunk) and it is not possible to check-in code for 3.2. Following this policy it would mean a feature freeze on trunk for an indefinite period of time.
As I said on IRC, that's not what I'm advocating. I'm advocating having 3.2 come out before 2.7, so that the new post-3.1 features get released to the public in 3.2 first, before appearing in 2.7. (Although "first" could alternatively mean the same day, if the community were up to for that). But like I said I'm not attached to the idea, just advocating it ;) --David
On Jun 7, 2009, at 12:55 PM, Martin v. Löwis wrote:
Assuming the policy "release new features for 2.x only after they got released for 3.x". I don't think such a policy actually exists.
The policy, as I remember it, can be summed up: don't innovate new features in the 2.x branch. Meaning, add it to 3.x first and then backport if you want. I don't believe a new feature has to be in a / released/ version of 3.x first for it to show up in the next 2.x release. -Barry
Martin v. Löwis wrote:
I don't think that the policy has been articulated in exactly that way, and it certainly wasn't implemented for 2.6/3.0. 2.6 was released with features that had not been released in any 3.x release, just because 3.x had not been released at all.
I don't think the idea of "3.x first" was raised explicitly until the discussions about having a short release cycle for 3.1 came up. Before then there was an assumption that 3.1 and 2.7 would come out at roughly the same time.
B. "Yes."
This answer means that the 3.1 to 3.2 development cycle will need to be truncated by roughly 6 months so that 3.2 can be released before 2.7 with any new features of interest. The 3.2 and 2.7 releases should then occur within a few months of each other.
Assuming the policy "release new features for 2.x only after they got released for 3.x". I don't think such a policy actually exists.
As RDM already mentioned, the potential problem such a policy is intended to address is the idea of being able to write 2.7 code that can't be forward ported to 3.x because no version with a corresponding feature set has been released yet. My last sentence above was actually deliberately ambiguous as to whether 2.7 or 3.2 ends up being released first - so long as the releases happen within a few months of each other and any new features that appear in 2.7 also appear in 3.2, then the migration path for different 2.x versions remains clear (i.e 2.6-only code can be migrated to 3.1, but 2.7 code may need to be migrated to 3.2 instead if it uses features that aren't in 3.1). The exact order and timing of 3.2/2.7 will no doubt depend on any specific issues relating to the two releases around the time that they come out. But in the interests of maintaining a coherent migration path from 2.x to 3.x, it makes sense to plan to release them at roughly the same time. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
Martin v. Löwis wrote:
I have thought that 2.7 was now to come out instead with 3.2 and would include backported 3.2 new features. Others expect 2.7 to come out soon after 3.1 and to only contain new 3.1 features. So Guido or someone, please clarify: is 2.7 to be the counterpart of 3.1 or 3.2? Neither, nor. 2.7 will be released 18..24 months after 2.6, i.e. between April 2010 and October 2010. I think it's too early to speculate about a release schedule for 3.2.
I think Terry's underlying question is more basic than that. It can also be phrased as:
"Is 2.7 allowed to have new features which did not appear in 3.1?"
That is the issue that came up in a Python list discussion when two people, including one who I expect to know as much as me about this, 'corrected' my 'yes' to "No, 2.7 will come out in a few months after 3.1." So there clearly is confusion on this and related issues (as I already see in the responses on this thread ;-). The answer makes some difference in how issues are handled on the tracker, which I occasionally help with.
In previous discussions, a general policy has been articulated that having released Python 3.0, any new features should appear in a 3.x release before they appear in a 2.x release. Following that policy (which I think is actually a good one) means there are certain consequences for the two possible answers to the above question:
A. "No."
This answer means that 2.7 will only contain new features that are part of 3.1. If 2.7 sticks to a normal 18-24 month release cycle the only activities on the trunk for the next 12 months or so should be backports from 3.1 and bug fixes. New features added to the py3k branch for 3.2 should not be backported until after 2.7 is released. The other alternative in this case is to release 2.7 earlier than normal, but that creates problems in terms of the absolute duration of maintenance branch support for 2.6.
I agree, but this is what two people are expecting.
B. "Yes."
This answer means that the 3.1 to 3.2 development cycle will need to be truncated by roughly 6 months so that 3.2 can be released before 2.7 with any new features of interest. The 3.2 and 2.7 releases should then occur within a few months of each other.
Releasing 2.7 early doesn't seem like a good idea to me and neither does putting the trunk into the equivalent of a feature freeze for 12 months or more. So I'm in favour of the idea of a paired 3.2/2.7 release late next year.
This is what I have been expecting,
I don't think that's a novel idea though - I'm pretty sure it was suggested (and met with general approval) when the idea of a short release cycle for 3.1 was first brought up.
I presume because it has been stated before. In addition to the question above, I am also trying to provoke thought on the nature and purpose of 2.7. Backporting features 'if someone feels like it' seems pretty haphazard. For someone wanting to maintain compatibility across multiple 2.x releases, a random new features may be nearly useless. Terry Jan Reedy
Terry Reedy wrote:
[snip...]
I don't think that's a novel idea though - I'm pretty sure it was suggested (and met with general approval) when the idea of a short release cycle for 3.1 was first brought up.
I presume because it has been stated before.
In addition to the question above, I am also trying to provoke thought on the nature and purpose of 2.7. Backporting features 'if someone feels like it' seems pretty haphazard. For someone wanting to maintain compatibility across multiple 2.x releases, a random new features may be nearly useless.
The "What's new in Python 2.7" list is already very impressive. :-) Michael
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/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
On Sun, Jun 7, 2009 at 6:21 AM, Terry Reedy <tjreedy@udel.edu> wrote:
I have thought that 2.7 was now to come out instead with 3.2 and would include backported 3.2 new features. Others expect 2.7 to come out soon after 3.1 and to only contain new 3.1 features. So Guido or someone, please clarify: is 2.7 to be the counterpart of 3.1 or 3.2?
Just my 0.02 cents, but struggling with all warts of 2.5 subprocessing in Windows I would vote for more time for stabilizating things - not adding new features. Long awaited subprocess as replacement for os.popen() AFAIK is still incapable to asynchronously communicate with spawned processes on Windows. I would call this feature as critical even on 2.6 As a release testcase - try porting pyexpect module to this platform. Absence of native curses/console/readline module also makes Python one-way unix shell language while many users expect it to be crossplatform. -- anatoly t.
anatoly techtonik <techtonik <at> gmail.com> writes:
Just my 0.02 cents, but struggling with all warts of 2.5 subprocessing in Windows I would vote for more time for stabilizating things - not adding new features. Long awaited subprocess as replacement for os.popen() AFAIK is still incapable to asynchronously communicate with spawned processes on Windows. I would call this feature as critical even on 2.6 As a release testcase - try porting pyexpect module to this platform. Absence of native curses/console/readline module also makes Python one-way unix shell language while many users expect it to be crossplatform.
As always, patches and proposals are welcome! However, as far as the above issues are concerned, it seems to be less a matter of time between releases than of motivation to get things done (tm). I don't think a knowledgeable and determined Windows programmer would have much trouble solving each of them. Regards Antoine.
Just my 0.02 cents, but struggling with all warts of 2.5 subprocessing in Windows I would vote for more time for stabilizating things - not adding new features. Long awaited subprocess as replacement for os.popen() AFAIK is still incapable to asynchronously communicate with spawned processes on Windows. I would call this feature as critical even on 2.6 As a release testcase - try porting pyexpect module to this platform. Absence of native curses/console/readline module also makes Python one-way unix shell language while many users expect it to be crossplatform.
I am not quite sure whether you are for new features or not. Your first sentence ("vote for ... not adding new features") seems to suggest that you would not like to see new features, and your last sentence ("absence of native curses/console/readline module") suggests that you *do* want to see new features (namely, a native curses module, and a native readline module). Which one is it? Regards, Martin
On Mon, Jun 8, 2009 at 11:01 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I am not quite sure whether you are for new features or not. Your first sentence ("vote for ... not adding new features") seems to suggest that you would not like to see new features, and your last sentence ("absence of native curses/console/readline module") suggests that you *do* want to see new features (namely, a native curses module, and a native readline module).
Which one is it?
I would like to see new features in Python, but only if they are cross-platform. Unfortunately, I do not possess C skills to make this happen, nor do I have deep understanding of Microsoft Visual Studio .project files to port Makefiles and GCC options even when codebase is available for windows. The level to make a contribution in this case is too high. The lack of free time makes it impossible to close the gap in one step leaving remnants of work-in-process that will make it harder to continue in future than to start from scratch. Perhaps the necessity to make it in one huge step could be compensated by incremental solution approach and development process if there was obvious centralized place to organize efforts AND provide clear visibility into progress made so far, initial plan, plan deviation and current status. Mailing lists are good for discussions, but that's all - information becomes outdated, text-too-much, no prompt reply often stops the progress. Perhaps I shift my problem from lack-of-skill into lack-of-tools direction, but being amazed by efforts people put into supporting this mailing list I most of the time unable to reply to emails I get mostly because replies require time for testing and proving facts. There is no definite proposal to solve problems of enabling OpenID or SSO for python.org, of porting curses to windows, of testing subprocessing etc., but there is an idea that some things could be given more visibility AND priority to allow people to see the big picture and focus on outstanding problems. Even though most people here know about big-things-to-fix, these things doesn't standout from the pile of issues in roundup. The thing I miss the most is ability to gather all information relevant to one problem in one place. This includes timeline with commits, branches, relevant issues, issue updates, relevant wiki edits, current focus URLs, _filtered_ threads and refactored comments. The problem is to ensure that this information is up to date and provide easy way/instruction how to bring it up to date in case something is broken. It is not necessary to meet the bus to experience the effect of bus factor. -- anatoly t.
participants (12)
-
"Martin v. Löwis" -
anatoly techtonik -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Lennart Regebro -
Michael Foord -
Nick Coghlan -
R. David Murray -
Stephen J. Turnbull -
Terry Reedy -
Tres Seaver