Get 2.5 changes in now, branch will be frozen soon
This is a reminder that the 2.5 branch will be frozen early next week. If there are changes you want to get into 2.5.1, they should be checked in within a few days. Be conservative! There will be a 2.5.2, it's better to wait than to have to make a new release for one rushed feature. If you don't believe, just wait until Anthony shows up at your doorstep. :-) n
Neal> If you don't believe, just wait until Anthony shows up at your Neal> doorstep. :-) And later sends you a bill for the airline tickets. ;-) Skip
On 3/30/07, skip@pobox.com <skip@pobox.com> wrote:
Neal> If you don't believe, just wait until Anthony shows up at your Neal> doorstep. :-)
And later sends you a bill for the airline tickets. ;-)
No, no. He just pays with the tickets from your bank account or credit card. Don't ask me how he does it. I really don't want to know. :-) n -- PS. And of course he flies first class all the way.
Neal Norwitz wrote:
This is a reminder that the 2.5 branch will be frozen early next week. If there are changes you want to get into 2.5.1, they should be checked in within a few days. Be conservative! There will be a
There's this bug (which includes the patch): #1688393. It's ok, solves a bug. I even commited it to the trunk (with test cases and all). I'm not working in the 2.5 branch, so if anybody makes me the favor... ;) -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
I'm sure everyone remembers the big ol' honking discussion on the change to os.splitext; it sorta fizzled after Guido asked if people would accept a pronouncement on the subject. I'm not anyone in the Python world, but felt strongly enough on the particular subject to submit a patch (and later revisions based upon the evolving conversation), but I think this should get resolved one way or the other. If the existing "fix" goes in for 2.5.1, then I'm going to withdraw said patch since I think it would end up doing more harm then good to silently change the semantics of how the function treats and defines extensions in one version only to do so again in another. The options, from how I see it, are: * The patch that Martin committed to fix the behavior such that splitext('.cshrc') returned ('.cshrc', '') remains. This would silently alter the behavior of a function whose tests have held the existing behavior correct; but it would make the behavior more logical in many situations. * The change gets simply reverted for now to return to the previous behavior, to perhaps be addressed later. This would revert to the status quo and its definition of 'extension' when it comes to files that have a leading dot, which may not be long-term desirable but which would at least give time for a plan and/or decision on the issue without a silent behavior adjustment. * The introduction of a keyword parameter to determine if the function should treat that initial dot as the start of an extension or a hidden filename. This would (IMHO) provide a migration path from the existing behavior which is a bit odd to the new behavior which makes more sense, while still allowing people to use whichever they choose to be appropriate for their domain. The question is also open on the issue of warnings; there was some sentiment that opposed a warning in this case (or in general) With the latter, another question is what the default is now; and will it change in the future. I just wanted to offer a gentle prod to see if a decision can be made; if any decision requires an adjustment to patches, tests and documentation, I'm willing to do them. Whatever the decision ends up being. On 3/29/07, Neal Norwitz <nnorwitz@gmail.com> wrote:
This is a reminder that the 2.5 branch will be frozen early next week. If there are changes you want to get into 2.5.1, they should be checked in within a few days. Be conservative! There will be a 2.5.2, it's better to wait than to have to make a new release for one rushed feature. If you don't believe, just wait until Anthony shows up at your doorstep. :-)
"Stephen Hansen" <apt.shansen@gmail.com> wrote:
I'm sure everyone remembers the big ol' honking discussion on the change to os.splitext; it sorta fizzled after Guido asked if people would accept a pronouncement on the subject. I'm not anyone in the Python world, but felt strongly enough on the particular subject to submit a patch (and later revisions based upon the evolving conversation), but I think this should get resolved one way or the other. If the existing "fix" goes in for 2.5.1, then I'm going to withdraw said patch since I think it would end up doing more harm then good to silently change the semantics of how the function treats and defines extensions in one version only to do so again in another.
Anthony Baxter said that the patch wasn't making it into 2.5.1, and since he is the release manager, his word is just about as final as Guido's (at least regarding the releases he does). - Josiah
Anthony Baxter said that the patch wasn't making it into 2.5.1, and since he is the release manager, his word is just about as final as Guido's (at least regarding the releases he does).
Ah, oops! Work got busy, and I must have missed that in the Endless Threads. Nevermind then. :) --S
[Stephen Hansen=
I just wanted to offer a gentle prod to see if a decision can be made; if any decision requires an adjustment to patches, tests and documentation, I'm willing to do them.
We should get a pronouncement on this or else whatever goes out in Py2.5.1 becomes the de-facto decision and becomes much harder to change. Raymond
Raymond Hettinger schrieb:
[Stephen Hansen=
I just wanted to offer a gentle prod to see if a decision can be made; if any decision requires an adjustment to patches, tests and documentation, I'm willing to do them.
We should get a pronouncement on this or else whatever goes out in Py2.5.1 becomes the de-facto decision and becomes much harder to change.
Changing 2.5.x was not ever proposed in the entire thread (up to now); the existing change is for 2.6 only. Regards, Martin
participants (7)
-
"Martin v. Löwis" -
Facundo Batista -
Josiah Carlson -
Neal Norwitz -
Raymond Hettinger -
skip@pobox.com -
Stephen Hansen