Re: [Python-Dev] Proposal to revert r54204 (splitext change)
On 16 Mar, 2007, at 23:37, Stephen Hansen wrote: That may actually be a genuinely useful approach: splitext(name, ignore_leading_dot=False, all_ext=False) ... that's perfect. I updated my patch to do it that way! :) I don't agree. all_ext=True is won't do the right thing in a significant subset of filenames:: archiveType = os.path.splitext(sourceArchive, all_ext=True) This won't do what you'd want with most source distributions on the internet (product-X.Y.Z.tar.gz). The ignore_leading_dot argument seems to be there to keep everyone happy and furthermore is an argument that will be passed a constant value in the majority of usecases (I'd say all uses, but that's just asking for someone to come up with a lame counterexample). The ignore_leading_dot argument also doesn't buy you anything that can't trivially be implemented in other ways. Ronald --S ___ 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/ ronaldoussoren%40mac.com ___ 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] Proposal to revert r54204 (splitext change)
At 09:24 AM 3/20/2007 +0100, Ronald Oussoren wrote: I don't agree. all_ext=True is won't do the right thing in a significant subset of filenames Yes, that's understood. The problem is that splitext() in general won't do the right thing, for many definitions of the right thing, unless you're applying it to a fairly constrained range of filenames, or unless you add other code. This won't change, unless we get rid of splitext() altogether. If you're trying to match an archive extension, for example, you'll probably need to loop on repeated splitext() calls until you find an extension that matches. One benefit of using both the new keyword arguments together is that it allows you to make your loop proceed from longest match to shortest, so that if you are matching product-X.Y.Z.tar.gz, you're going to go through matching .Y.Z.tar.gz, then .Z.tar.gz, then .tar.gz. The ignore_leading_dot argument also doesn't buy you anything that can't trivially be implemented in other ways. I don't understand. Example? ___ 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] Proposal to revert r54204 (splitext change)
Ronald Oussoren schrieb:
I don't understand. Example?
You conveniently ignored my other arguments ;-).
Given a splitext that ignores leading dot's the following function doesn't:
# from os.path import *
def splitext2(path):
dn = dirname(path)
bn, ext = splitext(basename(path))
if bn.startswith('.') and ext == '':
return dn, bn + ext
else:
return join(dn, bn), ext
I'd say that's a trivial function.
By that measure, the entire splitext function is trivial. However,
if you look closely, you find that even such a 'trivial' function
can contain many errors already, and it needs several revisions to
get it right.
This particular function has two errors (as far as I can see):
- if there are multiple leading dots, your version will return
all of them in ext, even though it's promised that ext will
contain exactly one dot. IOW, splitext2('...txt') should
give ('..', '.txt'), but does give ('', '...txt')
- The join() call will insert the module's separator, even
though the original string may have used the altsep. This
violates the promise that base+ext == path.
What I don't understand is why 'ignore_leading_dot==False' is considered
to be a valid usecase at all, except for the fact that os.path.splitext
did this until py2.5. I'm definitely in the camp that considers
'.profile' not to have an extension.
That is precisely the core of the discussion. It's not that
ignore_leading_dots=False is considered useful, in the call (except
for a few people that claim that splitext('.txt') ought to give
'','.txt'), but that the valid use case apparently is to not
pass any parameters, so that 100%, never-changing
backwards-compatibility is preserved.
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] Proposal to revert r54204 (splitext change)
At 04:47 PM 3/20/2007 +0100, Ronald Oussoren wrote:
On 20 Mar, 2007, at 15:54, Phillip J. Eby wrote:
At 09:24 AM 3/20/2007 +0100, Ronald Oussoren wrote:
I don't agree. all_ext=True is won't do the right thing in a
significant subset of filenames
Yes, that's understood. The problem is that splitext() in general
won't do the right thing, for many definitions of the right
thing, unless you're applying it to a fairly constrained range of
filenames, or unless you add other code. This won't change, unless
we get rid of splitext() altogether.
I know that, I actually read most of the messages in this thread. The
reason I'm pointing this out for the 'all_ext=True' case is that
adding this flag could give naive users even more reason to believe
that splitext will magicly do the right thing.
Well, that's where we need to shore up the documentation, which needs to
point out the folly of expecting DWIM. We should give some examples of
where splitext() will *not* DWIM.
If you're trying to match an archive extension, for example, you'll
probably need to loop on repeated splitext() calls until you find
an extension that matches. One benefit of using both the new
keyword arguments together is that it allows you to make your loop
proceed from longest match to shortest, so that if you are matching
product-X.Y.Z.tar.gz, you're going to go through
matching .Y.Z.tar.gz, then .Z.tar.gz, then .tar.gz.
I don't know if this is worth the additional API complexity.
Especially given the inherit problems of a splitext function.
The ignore_leading_dot argument also doesn't buy you anything that
can't
trivially be implemented in other ways.
I don't understand. Example?
You conveniently ignored my other arguments ;-).
Given a splitext that ignores leading dot's the following function
doesn't:
# from os.path import *
def splitext2(path):
dn = dirname(path)
bn, ext = splitext(basename(path))
if bn.startswith('.') and ext == '':
return dn, bn + ext
else:
return join(dn, bn), ext
I'd say that's a trivial function.
What I don't understand is why 'ignore_leading_dot==False' is
considered to be a valid usecase at all, except for the fact that
os.path.splitext did this until py2.5. I'm definitely in the camp
that considers '.profile' not to have an extension.
Okay, the part I'm confused about is what's your position on what should be
*done* about this. Are you favoring no change? Deprecating it and ripping
it out? Or what?
___
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] Proposal to revert r54204 (splitext change)
On 20 Mar, 2007, at 19:24, Phillip J. Eby wrote: What I don't understand is why 'ignore_leading_dot==False' is considered to be a valid usecase at all, except for the fact that os.path.splitext did this until py2.5. I'm definitely in the camp that considers '.profile' not to have an extension. Okay, the part I'm confused about is what's your position on what should be *done* about this. Are you favoring no change? Deprecating it and ripping it out? Or what? os.path.splitext works fine for what it is supposed to do, even though there currently is some confusion on what that is. IMHO the change Martin checked in into 2.6 was a good one and makes that API as good as it can get without unduly cluttering the API. Ronald smime.p7s Description: S/MIME cryptographic 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] Proposal to revert r54204 (splitext change)
At 05:07 PM 3/20/2007 +0100, Martin v. Löwis wrote:
Ronald Oussoren schrieb:
What I don't understand is why 'ignore_leading_dot==False' is considered
to be a valid usecase at all, except for the fact that os.path.splitext
did this until py2.5. I'm definitely in the camp that considers
'.profile' not to have an extension.
That is precisely the core of the discussion. It's not that
ignore_leading_dots=False is considered useful, in the call (except
for a few people that claim that splitext('.txt') ought to give
'','.txt')
Actually, *this* is precisely the problem: arguing that the opinion of
these few people is irrelevant, because a few *other* people think
they're wrong to find that behavior useful.
I'm able to see that considering '.profile' to not have an extension is a
*reasonable* position to take, and that doing it from the start *might*
have been a good idea.
What I disagree with is punishing people who considered the opposite
approach equally valid, and took the documentation and tests at their word.
Breaking their code without warning would be rude enough, but unfortunately
it affects not only the person who directly uses splitext(), but everyone
who uses any library, tool, or application that relies on the current behavior.
The very fact that you keep treating the current behavior as *not* useful
is the very core of our disagreement. Indeed, it seems to me quite
disrespectful that you will not take anyone at their word that they do
indeed expect, desire, and *value* the existing behavior, and wish to
continue to have access to it in future versions of Python.
Suppose that the behavior had been the other way around to begin with, and
Windows users started filing bugs about it, because it disagrees with
Windows Explorer's interpretation of the extension? Would you simply
change the Unix-oriented behavior because it's clearly a bug?
If not, then what is your rationale for changing it the other way? Make no
mistake: both behaviors are desirable, for different reasons. And both
interpretations merely reflect platform-specific shell policies, so neither
is any more true or correct in some absolute sense. (If anything,
Windows at least derives from an operating system that actually *has*
extensions as part of its filesystem, whereas Unix does not.)
The people who would like to keep the old behavior have all, to my
recollection, acknowledged that other behaviors are desirable. Why won't
the people who want to *change* the behavior acknowledge the same thing?
___
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] Proposal to revert r54204 (splitext change)
On 3/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Let me take the opportunity to make this clear, then. I have the utmost respect for Martin and his contributions for Python. I have been following commits for quite a while and I know that Martin, in particular, is often the one who deals with the crap work of reviewing huge piles of orphaned patches and fixing piles of minor issues, and he is therefore responsible for much of the general upward trend in Python's overall quality in the last few releases. I appreciate that very much. Thanks. My first observation is that this is a tempest in a teacup. On the one hand I agree. This particular change is trivial, most likely doesn't affect me, and I accept that, in practice, it probably won't even break too many programs (and may even fix a few). Then why was there such an upheaval when it was submittedd? On the other, I think it is important to quell the tempest before it exits the teacup. Previously in this discussion, both I and PJE have repeatedly declared that this _particular_ change is not really what's at issue here, merely the pattern of reasoning that comes to consider this change acceptable. At some point a large number of small breakages are actually worse than one big one, and it's hard to point to the exact place where that happens. I think you're missing my point here. At issue is a judgement call, not an adjustment of the rules. Everybody knows that we fix bugs mercilessly but are very careful with deprecating features. At issue is the judgement about whether a particular changes is a bug or a feature. I don't accept the position that since there are unit tests and docs for it, it must be a feature; those could well have been produced without much thinking and after the fact (I *know* they were produced after the fact since splitext() long predates our first unit test). So if there's any new rule required, it's not a rule for defining more clearly the definition of bug vs. feature, but a rule for what to do if you disagree with a change (whether committed or proposed). But that falls in the realm of human behavior, and I very much doubt we can write a PEP for that. Even if we could, I really don't think I'd like the result; I'm not into having a court of appeals or any such formal solution. To be concrete, I think that if Phillip had written a different kind of post instead of the one where he requests the reversal of the submit (only parenthetically mentioning Martin) then perhaps Martin wouldn't have felt the need to dig in and defend his position, and the issue might have been resolved quicker and at less emotional expense. I see small discussions on python-checkins all the time where someone comments on someone else's checkin, and the tone of the comment makes all the difference. On the gripping hand, I am almost glad that it was a relatively minor change that triggered this avalanche of posts. Even with such a small change, the change itself threatens to obscure a larger issue, and if the change itself were any bigger, it would eclipse the other discussion completely. One recommendation I have for discussions like this (thanks to Stephen Turnbull in private mail) is to attempt to separate in your mind (and in everyone's mind) the distinction between the change at hand and the policy discussion. Muddling these two together makes for a poor discussion of the feature and an even poorer discussion of policy change. My third observation is tha a policy that would have disallowed or allowed (depending on your POV) this particular change is not an option. A policy isn't going to solve all disagreements, there will always be debate possible about the interpretations of the rules. What's needed is a way to handle such debate in a way that produces an outcome without wearing everyone out. The allow vs. disallow issue is not *really* what the policy should be addressing. A major problem with this thread is the differing definitions that some people have, beginning with extension, but I can't see that a policy will fix *that*. Words like bug, fix, compatible, and so on, all have obvious general meanings but much more nuanced and specific meanings in particular contexts. A policy should outline specifics of what, for example, is to be considered an incompatible change, and what must be done in that case. A policy could not outright forbid changes of a certain type, since that is pretty much asking that it be broken any time a sufficiently important change is requested and the core team likes it. IMO all the policy we need is PEP 5. It wisely defers to common sense regarding the implementation, and that's where I want to re-focus the discussion. Maybe policy isn't even the right word here, since the part of it that would facilitate discussions like this one would be more lexicon than policy. The crux is in trying to define major. That's vague, and intentionally so; I think it would
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
At 12:53 PM 3/18/2007 -0700, Guido van Rossum wrote: This is an experiment for me as well; if you all would prefer me to stay out of it, I will. With respect to the specific change, it seems to me that there is an emerging consensus for adding keyword arguments to support the new behaviors, so I'm not sure a pronouncement is needed. As far as I'm aware, the main question left open is whether the default behavior should change in a future version of Python, and if so, which version. To be concrete, I think that if Phillip had written a different kind of post instead of the one where he requests the reversal of the submit (only parenthetically mentioning Martin) then perhaps Martin wouldn't have felt the need to dig in and defend his position, and the issue might have been resolved quicker and at less emotional expense. Martin's position was already abundantly clear; the fact that he had checked in the change despite prior opposition demonstrated that a personal appeal was already moot -- the digging in had already taken place a week or two prior, when the use cases were first presented and objections were first raised, and Martin simply dropped the discussion and checked it in anyway. He left my last message in that discussion (laying out a detailed rationale for rejecting the change) without a reply: http://mail.python.org/pipermail/python-dev/2007-March/071798.html So I was absolutely stunned when I found the change had been checked in, anyway. To be concrete, if Martin had spent less time trying to discredit and discard the use cases of the people being polled about the question, a compromise could perhaps have been reached *before* he applied the patch, and the second discussion would never have needed to happen. In other words, the second discussion was the *result* of Martin digging in and ignoring objections, not the cause of it. I'm trying to stay out of the feature discussion, but I would like to point out that a policy that, in the sake of some strict definition of backwards compatibility, forces us to introduce new APIs (or new optional parameters to existing ones, which is really the same thing) at a high rate is also doomed to have an overall detrimental effect on the language -- who know, perhaps more so than the occasional incompatible change. I don't advocate a mechanically-enforced policy, either. But it seems to me that when a behavior is documented and has valid use cases, changing the behavior to benefit people who *didn't* pay any attention to the documentation or test their code for corner cases is punishing the vigilant to aid the ignorant, and that seems unwise for us as a community. Likewise, attempting to retroactively fix latent bugs for one group at the cost of introducing latent bugs for another group doesn't seem like a net improvement. ___ 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby wrote: At 12:53 PM 3/18/2007 -0700, Guido van Rossum wrote: This is an experiment for me as well; if you all would prefer me to stay out of it, I will. With respect to the specific change, it seems to me that there is an emerging consensus for adding keyword arguments to support the new behaviors, so I'm not sure a pronouncement is needed. As far as I'm aware, the main question left open is whether the default behavior should change in a future version of Python, and if so, which version. To be concrete, I think that if Phillip had written a different kind of post instead of the one where he requests the reversal of the submit (only parenthetically mentioning Martin) then perhaps Martin wouldn't have felt the need to dig in and defend his position, and the issue might have been resolved quicker and at less emotional expense. Martin's position was already abundantly clear; the fact that he had checked in the change despite prior opposition demonstrated that a personal appeal was already moot -- the digging in had already taken place a week or two prior, when the use cases were first presented and objections were first raised, and Martin simply dropped the discussion and checked it in anyway. He left my last message in that discussion (laying out a detailed rationale for rejecting the change) without a reply: http://mail.python.org/pipermail/python-dev/2007-March/071798.html So I was absolutely stunned when I found the change had been checked in, anyway. To be concrete, if Martin had spent less time trying to discredit and discard the use cases of the people being polled about the question, a compromise could perhaps have been reached *before* he applied the patch, and the second discussion would never have needed to happen. In other words, the second discussion was the *result* of Martin digging in and ignoring objections, not the cause of it. I'm trying to stay out of the feature discussion, but I would like to point out that a policy that, in the sake of some strict definition of backwards compatibility, forces us to introduce new APIs (or new optional parameters to existing ones, which is really the same thing) at a high rate is also doomed to have an overall detrimental effect on the language -- who know, perhaps more so than the occasional incompatible change. I don't advocate a mechanically-enforced policy, either. But it seems to me that when a behavior is documented and has valid use cases, changing the behavior to benefit people who *didn't* pay any attention to the documentation or test their code for corner cases is punishing the vigilant to aid the ignorant, and that seems unwise for us as a community. Likewise, attempting to retroactively fix latent bugs for one group at the cost of introducing latent bugs for another group doesn't seem like a net improvement. But isn't this, despite the force or otherwise of your arguments, simply *you* digging in in response to what you perceive as Martin's truculence? There's little point at this stage repeating arguments you have already put forward, since those who were convinced by them remain convinced and vice versa. I believe Guido still wants to know whether you will accept a pronouncement. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Recent Ramblings http://holdenweb.blogspot.com ___ 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] Proposal to revert r54204 (splitext change)
At 12:43 PM 3/19/2007 -0400, Steve Holden wrote: Phillip J. Eby wrote: At 12:53 PM 3/18/2007 -0700, Guido van Rossum wrote: This is an experiment for me as well; if you all would prefer me to stay out of it, I will. With respect to the specific change, it seems to me that there is an emerging consensus for adding keyword arguments to support the new behaviors, so I'm not sure a pronouncement is needed. As far as I'm aware, the main question left open is whether the default behavior should change in a future version of Python, and if so, which version. [snip] I believe Guido still wants to know whether you will accept a pronouncement. Actually, he asked first if we *want* him to make one, and my answer to that is above: I don't think it's necessary. Like Martin, I believe we are within sight of a consensus. And I think that's better for Python and Python-Dev than dragging Guido into it. ___ 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby schrieb: Actually, he asked first if we *want* him to make one, and my answer to that is above: I don't think it's necessary. Like Martin, I believe we are within sight of a consensus. And I think that's better for Python and Python-Dev than dragging Guido into it. I apparently missed your specific alternative proposal (I assume it is not revert anymore?) 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] Proposal to revert r54204 (splitext change)
At 06:28 PM 3/19/2007 +0100, Martin v. Löwis wrote: Phillip J. Eby schrieb: Actually, he asked first if we *want* him to make one, and my answer to that is above: I don't think it's necessary. Like Martin, I believe we are within sight of a consensus. And I think that's better for Python and Python-Dev than dragging Guido into it. I apparently missed your specific alternative proposal (I assume it is not revert anymore?) In general, I support the keyword argument approach, as in the patch you referred to. Specifically, however, I would prefer to see it without the warning and future change, as I don't think it provides any real benefit. Either way, some people will have to use a keyword to get what they want, so making a change seems unnecessary. However, if we have to change something in a future version, I would suggest we make that option a required argument, on EIBTI grounds. That way, in 2.6 you can simply make it explicit to be 3.x-compatible. And, I think the warning (if any) should be treated as any other 3.x warning. But as I said, I gather that this aspect of the question is the main open issue remaining to be resolved, since you've also expressed support for the keyword approach, as have many others. ___ 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] Proposal to revert r54204 (splitext change)
Specifically, however, I would prefer to see it without the warning and future change, as I don't think it provides any real benefit. Either way, some people will have to use a keyword to get what they want, so making a change seems unnecessary. However, if we have to change something in a future version, I would suggest we make that option a required argument, on EIBTI grounds. That way, in 2.6 you can simply make it explicit to be 3.x-compatible. And, I think the warning (if any) should be treated as any other 3.x warning. But as I said, I gather that this aspect of the question is the main open issue remaining to be resolved, since you've also expressed support for the keyword approach, as have many others. So will you also either pick one of the proposals, or come up with your own patch? I still think that some has to make a decision, and it won't be me. 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] Proposal to revert r54204 (splitext change)
delurk On Windows it's correct that splitext(.txt)[1] == splitext(foo.txt)[1] and an implementation in which this is not true would be considered buggy. On *ix it's correct that splitext(.txt)[1] != splitext(foo.txt)[1] and the current behaviour is considered buggy. Since programmer expectations are platform-specific, regardless of whether keywords are used or not, why not make the default behaviour platform-specific and document that it's so? Alternatively, if a new path implementation ever gets up, a more neutral solution might be to have a platform-specific Path.filetype, which could handle Mac resources.. /delurk Cheers, -T ___ 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] Proposal to revert r54204 (splitext change)
On 19 Mar, 02:46 pm, [EMAIL PROTECTED] wrote: As you see I'm trying to discourage you from working on such a document; but I won't stop you and if there's general demand for it and agreement I'll gladly review it when it's ready. (It's a bit annoying to have to read long posts alluding to a document under development without being able to know what will be in it.) Quite so. Again, I apologize for that. I won't say anything further until I have something ready to post for review, and at that point I hope the motivation section will make it clear why I think this is so important. I estimate something this weekend. ___ 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] Proposal to revert r54204 (splitext change)
Now that this thread has celebrated its 100th message, I feel compelled to say something. My first observation is that this is a tempest in a teacup. My second observation is that there seems to have been a lack of people skills all around. That is perhaps to expect in a community of geeks, but given the length of the previous thread on this topic (before Martin checked it in) I think all the participants might have done wiser by taking each others' feelings into account rather than attempting to relentlessly arguing the technical point at hand. My third observation is tha a policy that would have disallowed or allowed (depending on your POV) this particular change is not an option. A policy isn't going to solve all disagreements, there will always be debate possible about the interpretations of the rules. What's needed is a way to handle such debate in a way that produces an outcome without wearing everyone out. It's important that the participants in the debate respect each other -- before, during and after the debate. If you want, I can make a decision. But I will only do that if I hear from both sides of the debate that they are willing to accept my choice even if it favors the other party. Can I hear agreement to that? In particular; Phillip and Glyph, if I decide that Martin's change is OK for 2.6, will you accept it and stop debating it and get on with your lives? And Martin, if I decide that the change should be rolled back, will you be okay with that? This is an experiment for me as well; if you all would prefer me to stay out of it, I will. I haven't made up my mind yet about the technical issue, but I'm not interested in hearing the arguments repeated; I've heard them all and just need to mull it over. Let me know. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Proposal to revert r54204 (splitext change)
Guido van Rossum schrieb: And Martin, if I decide that the change should be rolled back, will you be okay with that? Certainly. I would wish somebody contributed a documentation patch pointing out that specific detail in the documentation (and in the process making the documentation match the implementation in the first place), but if nobody comes along, I would do that myself. This is an experiment for me as well; if you all would prefer me to stay out of it, I will. I would hope that we can agree to something that has been proposed as an alternative in http://python.org/sf/1681842 (suggesting a warning message and keyword arguments), or the two-step change that Thomas proposed, so you may want to watch this going on for a little while longer. However, I don't feel qualified anymore to trust my intuition on what changes are acceptable and which aren't, so it would be for some other committer (perhaps Thomas or Phillip) to actually implement such a change. HTH, 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] Proposal to revert r54204 (splitext change)
Guido van Rossum wrote: If you want, I can make a decision. But I will only do that if I hear from both sides of the debate that they are willing to accept my choice even if it favors the other party. Can I hear agreement to that? From me - definitely. I put my position forward (anti this change, partly because it only addressed one of the special cases), and then stayed out of it. Happy mulling! Tim Delaney ___ 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] Proposal to revert r54204 (splitext change)
Delaney, Timothy (Tim) wrote: From me - definitely. Damned Outlook, reformatting sent emails! That statement was obviously from me ... Tim Delaney ___ 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] Proposal to revert r54204 (splitext change)
On 18 Mar, 07:53 pm, [EMAIL PROTECTED] wrote: My second observation is that there seems to have been a lack of people skills all around. That is perhaps to expect in a community of geeks, but given the length of the previous thread on this topic (before Martin checked it in) I think all the participants might have done wiser by taking each others' feelings into account rather than attempting to relentlessly arguing the technical point at hand. Let me take the opportunity to make this clear, then. I have the utmost respect for Martin and his contributions for Python. I have been following commits for quite a while and I know that Martin, in particular, is often the one who deals with the crap work of reviewing huge piles of orphaned patches and fixing piles of minor issues, and he is therefore responsible for much of the general upward trend in Python's overall quality in the last few releases. I appreciate that very much. My first observation is that this is a tempest in a teacup. On the one hand I agree. This particular change is trivial, most likely doesn't affect me, and I accept that, in practice, it probably won't even break too many programs (and may even fix a few). On the other, I think it is important to quell the tempest before it exits the teacup. Previously in this discussion, both I and PJE have repeatedly declared that this _particular_ change is not really what's at issue here, merely the pattern of reasoning that comes to consider this change acceptable. At some point a large number of small breakages are actually worse than one big one, and it's hard to point to the exact place where that happens. On the gripping hand, I am almost glad that it was a relatively minor change that triggered this avalanche of posts. Even with such a small change, the change itself threatens to obscure a larger issue, and if the change itself were any bigger, it would eclipse the other discussion completely. My third observation is tha a policy that would have disallowed or allowed (depending on your POV) this particular change is not an option. A policy isn't going to solve all disagreements, there will always be debate possible about the interpretations of the rules. What's needed is a way to handle such debate in a way that produces an outcome without wearing everyone out. The allow vs. disallow issue is not *really* what the policy should be addressing. A major problem with this thread is the differing definitions that some people have, beginning with extension, but I can't see that a policy will fix *that*. Words like bug, fix, compatible, and so on, all have obvious general meanings but much more nuanced and specific meanings in particular contexts. A policy should outline specifics of what, for example, is to be considered an incompatible change, and what must be done in that case. A policy could not outright forbid changes of a certain type, since that is pretty much asking that it be broken any time a sufficiently important change is requested and the core team likes it. Maybe policy isn't even the right word here, since the part of it that would facilitate discussions like this one would be more lexicon than policy. It's important that the participants in the debate respect each other -- before, during and after the debate. Agreed. Any lack of people skills notwithstanding, I hope I haven't said anything that implied (or stated, of course) that I did not *respect* the other participants of the discussion. If I have, I retract it. Strong disagreement is different than disrespect. If you want, I can make a decision. But I will only do that if I hear from both sides of the debate that they are willing to accept my choice even if it favors the other party. Can I hear agreement to that? In particular; Phillip and Glyph, if I decide that Martin's change is OK for 2.6, will you accept it and stop debating it and get on with your lives? And Martin, if I decide that the change should be rolled back, will you be okay with that? I will certainly accept the decision. I don't *like* generating trouble on this mailing list, believe me. Once a BDFL pronouncement is made, further discussion is just generating trouble. That isn't the same as *agreeing* with the decision, of course :-). The important thing for me is not reaching a decision on this particular issue (or even a particular decision on this particular issue). It is that we achieve some kind of consensus around how backward compatibility is supposed to work in the large rather than in a particular instance. For those of you who don't think this issue is important in and of itself, consider the secondary consequence of this ruckus happening every time someone commits a potentially-incompatible change. I would not mind if, for example, this patch were grandfathered in to the lack of any clear backwards compatibility policy, as long as similar future changes were subject to
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
Patrick Maupin wrote: On 3/16/07, Steve Holden [EMAIL PROTECTED] wrote: [...] Then I can stop wasting everyone's time. Even though I am no fonder of code breakage than I was. Fortunately, for new code (at least for this particular change!), you don't have to worry about breakage. I'm sure this discussion has been so indelibly etched into your brain that you won't forget to check your filename management functions very carefully. Sorry, were you being sarcastic? I didn't realize that. Or am I prevaricating again? I don't know whether you are prevaricating again, but I can definitely confirm I wasn't being sarcastic. I don't think sarcasm helps in a discussion like this. I was just apologizing to the group for a rat hole I drew the thread down briefly before someone (Martin, I think) pointed out the incompleteness/incorrectness of my reply. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ 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] Proposal to revert r54204 (splitext change)
On Thu, Mar 15, 2007, Martin v. L??wis wrote: I'm not quite sure what it is, here. If it is that there be no incompatible changes in Python: this is not policy, and not even consensus. Instead, policy (as enforced by the release manager), and consensus is that bug fix releases (2.x.y) must not show incompatible behavior. For feature releases (2.x), incompatible behavior is acceptable (at least this is what I thought consensus is, but apparently I'm wrong). You are not wrong on one level, but you are wrong on another: if a change that may not be a bugfix gets any legitimate objections, the bar for the change becomes much higher, and that goes double or triple if the change will result in silent breakage of existing programs. If this discussion had occurred three years ago, I would be more inclined toward your position, but right now we have another outlet for silent incompatible changes: Python 3.0. I'm not opposed to extending the splitext API in 2.6 as one solution for this problem, but I still believe that pushing the change to 3.0 is best (assuming we make the change at all, because the people arguing against any change do have a point about Windows -- and in the end, Windows is the largest CONSUMER of Python programs). I do agree with the surprise expressed about your claim that extending the API isn't backward compatible -- the point is that any code using pre-2.6 splitext() API will work the same across 2.x regardless of whether the code is written after 2.6 is released. Of course anyone who uses the extended API is backward incompatible, but that's a much different kind of problem. Because this discussion has gone on so long, it seems to me that a micro-PEP would be good for summarizing. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I disrespectfully agree. --SJM ___ 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] Proposal to revert r54204 (splitext change)
On 3/15/07, Terry Reedy [EMAIL PROTECTED] wrote: As to the usefulness of current behavior, the only supposed use-case code posted, that I have noticed, was that it made it easy to turn '.emacs' into '1.emacs', but then MK said the app does not really do that. I said the name .emacs was used as an example. For that matter, the name a.txt was also used as an example. The use cases are real. Mike ___ 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] Proposal to revert r54204 (splitext change)
On 16/03/07, Phillip J. Eby [EMAIL PROTECTED] wrote: What's *actually* under dispute here is whether it's acceptable to classify this perfectly useful-as-is behavior, that was documented and tested in released versions of Python for several years (with patches to change its behavior explicitly rejected in the past), as a bug. Just to put this into context, the word bug is probably not the best to use here. The orignal behaviour was described as a bug, certainly, but that's not how the change has been treated. If the behaviour was being deemed a bug, it would be acceptable in a bugfix release (ie. 2.5.1). No-one is advocating that. Rather, the change is being treated as a behaviour change (which it is) and submitted for a *feature* release (2.6). Whether the behaviour change is good, reasonable, acceptable - that's the question here. (And one on which I don't have an opinion!) 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] Proposal to revert r54204 (splitext change)
On 3/14/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Wouters schrieb: However, changing documented, tested behaviour without warning gives Python an even worse name. I agree with PJE that the change is the wrong thing to do, simply because it sets (yet another) precedent. If providing an alternate API with clearer semantics is too 'heavy-weight' a solution and warning is for some reason unacceptable (I don't see why; all the arguments against warning there go for *any* warning in Python) -- then the problem isn't bad enough to fix it by breaking other code. I think producing pointless warnings also gives Python a bad name (I've seen many complaints about Python's warnings in the past, in particular when they fill up Apache log files). I would be more pissed if my apache logfiles were full of errors, instead :-) But perhaps we should be more forward about the use of warnings: warn people (so to speak) about warnings, and tell them about the -W option for making them louder/quieter. However, if everybody (and here I mean everybody) can agree that adding a warning to the current implementation would be an acceptable compromise, I could agree to such a compromise also (although I would prefer if somebody else took the blame for adding that warning. I happily take the blame for changing the behavior). What specific warning would you propose, and in what specific circumstance would it be issued? Hah, everyone agree? They weren't agreeing when you changed it, either :) But no, we don't add a warning *and* change the API. We add a warning *about* changing the API. 2.6 sees no semantic change, just a warning when os.path.splitext is used on a dotfile with no extension (or a file with an extension but no name, so you will.) 2.7/3.0 see the change in semantics. We do this for three reasons: - People who rely on the documented, tested, ages-old behaviour will get fair warning that the behaviour will change. I don't mean just programmers. I mean users, too. Yes, users will get to see the warning and many of them might not be able to do something about it. Well, considering this class of users would get a behavioural change, and quite likely a bug, giving them a warning hardly seems intrusive. - People who (inadvertently) rely on the new behaviour get a warning that their code is currently bugged. This includes users, too, of course: they get a warning that this program is bugged in older versions of Python. If there was a way to telepathically warn the actual programmer, that would be better, but there isn't, so we can't. We will have to use the user as the messenger. Furthermore, even if the original programmer is a user of his or her own program and uses Python 2.6, he or she may never trigger the erroneous behaviour himself. The user who got the warning is the only one who can tell him or her that there's a problem with dotfiles. (Even though only a small fraction of the actual users will send in a bug -- it's still the best we can do.) - Most importantly, people who don't care about the change, whose code works acceptibly with either version of os.path.splitext, will get warned about the change in behaviour. If, as in one of the given examples in this thread, files are renamed based on their 'extension', it may work either way, and it may make sense either way, but it will *change*. Files may end up being differently renamed. I don't see that as acceptible behaviour, for upgrading python to cause a subtle but noticeable change in how a program does its work -- without error. That's why we warn. There is a big difference between fixing this, and fixing bugs that are obviously bugs: functions that behave differently from the documentation or (if not documented) in obviously wrong ways. If you need to wonder what 'obvious' means: if the average programmer using the function does not realize he's getting 'incorrect' behaviour, it's not obviously wrong. This entire thread should make it obvious that os.path.splitext's old behaviour, while nonsensical if you think about it, is not *obviously* wrong. If os.path.splitext(.dotfile) were to return (.dotfile, .dotfile), that would be obviously wrong. What it does now is not. Changing it is the right thing, but changing it without first warning about it is not. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby schrieb: Some other options: 1. Deprecate splitext() and remove it in 3.0 How would that help the problem? Isn't it useful to have a function that strips off the extension? 2. Add an optional flag argument to enable the new behavior How would that help backwards compatibility? 3. Create a new function with the new behavior (as you proposed the last time there was a patch submitted for this) What to do with the old function in this case? 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] Proposal to revert r54204 (splitext change)
Thomas Wouters schrieb:
Hah, everyone agree? They weren't agreeing when you changed it, either
:) But no, we don't add a warning *and* change the API. We add a warning
*about* changing the API. 2.6 sees no semantic change, just a warning
when os.path.splitext is used on a dotfile with no extension (or a file
with an extension but no name, so you will.) 2.7/3.0 see the change in
semantics.
Would you like to work on that? Feel free to undo my changes as needed,
although I think the merging of the various implementations of splitext
can be kept, as should the additional test cases (just with a different
outcome). The tracker reports need to be updated to indicate the change,
too.
- People who rely on the documented, tested, ages-old behaviour will
get fair warning that the behaviour will change. I don't mean just
programmers. I mean users, too. Yes, users will get to see the warning
and many of them might not be able to do something about it. Well,
considering this class of users would get a behavioural change, and
quite likely a bug, giving them a warning hardly seems intrusive.
Here I disagree. I believe many people will see the warning that won't
see any behavior change (except for temporarily getting a warning).
Much code will do
for fn in os.listdir(path):
if os.path.splitext(fn)[1] in ('.c', '.h', '.vcproj'):
some_action
This code will be unaffected by the change, unless people have
a file called .c in a directory.
- People who (inadvertently) rely on the new behaviour get a warning
that their code is currently bugged. This includes users, too, of
course: they get a warning that this program is bugged in older versions
of Python. If there was a way to telepathically warn the actual
programmer, that would be better, but there isn't, so we can't. We will
have to use the user as the messenger.
But we do warn the programmer: there is a change in the documentation
(not just Misc/NEWS).
What it does
now is not. Changing it is the right thing, but changing it without
first warning about it is not.
Ok, I can accept a solution that will allow it to be changed eventually,
although I'm not happy with producing a warning. So, as I said, if
somebody wants to commit such a change, go ahead. If you want me to
review it first, I can do that as well.
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] Proposal to revert r54204 (splitext change)
Patrick Maupin schrieb: The worst part is, if they are relying on that specific behavior and have to rely on the new specific behavior, and want to support old and new versions of Python, they are potentially left with some very unattractive options -- check the Python version to figure out how splitext works, or just roll their own and stop calling splitext entirely, because its behavior is not consistent across versions. Somebody has pointed out that it is fairly easy to write a wrapper around splitext that explicitly produces the old behavior on all versions, or the new behavior on all versions, depending on what precisely is desired. Users that have coded for a specific behavior will have to write a wrapper - whether they explicitly code for the old behavior or the new one. 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] Proposal to revert r54204 (splitext change)
Martin v. Löwis wrote: Phillip J. Eby schrieb: Some other options: 1. Deprecate splitext() and remove it in 3.0 How would that help the problem? Isn't it useful to have a function that strips off the extension? 2. Add an optional flag argument to enable the new behavior How would that help backwards compatibility? By providing it! The suggestion would retain the same behavior unless a newly-specified aspect of the API is exercised, therefore avoiding gratuitous change to existing programs' functionality. Since the default would be to behave as the existing function does then you would have to specify a True value for the strange-and-incomprehensible-treatment-of-dotfiles to get the behavior as specified in the patch you just applied. This seems like the best option to me, as clearly there are enough different opinions about whether the old or the new behavior is a bug that a user-selectable behavior is actually desirable. My suspicion is that most users just won't care about dotfiles, and will continue to use splitext as is. Windows users are always surprised to see them appearing, but they are becoming more common as open source functionality migrates to Windows. But those who do care (as you obviously do) can use bizarreAndInexplicableDotfileBehavior=True ;-) 3. Create a new function with the new behavior (as you proposed the last time there was a patch submitted for this) What to do with the old function in this case? Presumably keep it, thereby adding to the bloat in the language - definitely NOT my preferred option. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ 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] Proposal to revert r54204 (splitext change)
Martin v. Löwis wrote: Patrick Maupin schrieb: The worst part is, if they are relying on that specific behavior and have to rely on the new specific behavior, and want to support old and new versions of Python, they are potentially left with some very unattractive options -- check the Python version to figure out how splitext works, or just roll their own and stop calling splitext entirely, because its behavior is not consistent across versions. Somebody has pointed out that it is fairly easy to write a wrapper around splitext that explicitly produces the old behavior on all versions, or the new behavior on all versions, depending on what precisely is desired. Users that have coded for a specific behavior will have to write a wrapper - whether they explicitly code for the old behavior or the new one. How is forcing people to write such a wrapper better than providing an optional argument (defaulting to current behavior) to specify the behavior they want? Presumably people who already care enough to want the patched behavior have already written such a wrapper around the current version. This should continue to work, albeit with less than exemplary efficiency. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ 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] Proposal to revert r54204 (splitext change)
At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote: Phillip J. Eby schrieb: Some other options: 1. Deprecate splitext() and remove it in 3.0 How would that help the problem? Isn't it useful to have a function that strips off the extension? Not if there's no consensus as to what extension means. Proposals to add sorted dictionaries or routines to add non-duplicate items to a list or to flatten data structures are routinely rejected for the same reason: users are recommended to write a routine that does what their particular application needs. 2. Add an optional flag argument to enable the new behavior How would that help backwards compatibility? All existing calls to splitext() would work the same way they've done for several years, and the documentation would now make it obvious to new users of the function that there's a choice about how to handle dotfiles. Heck, we could throw in another optional argument to strip multiple extensions like .tar.gz. For that matter, the documentation should address the issue that no matter what options you use, you may *still* end up with unexpected results, for files like Release 1.2, due to the fuzzy nature of the concept of a file extension on modern OSes. 3. Create a new function with the new behavior (as you proposed the last time there was a patch submitted for this) What to do with the old function in this case? Leave it alone - it's not broken. If people have buggy programs because they assumed '.foo' files were handled in a way that the docstrings and tests clearly indicate they are *not*, and they didn't test their *own* program, it's not Python's responsibility to fix their programs. ___ 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] Proposal to revert r54204 (splitext change)
At 01:47 AM 3/16/2007 -0400, Terry Reedy wrote: I think it is a ludicrous comparison, not even in the same ballpark, that tends to discredit the valid points you have made. Of course it's not in the same ballpark. The point was to show how ludicrous the *logic* is, by applying it to something that's more obviously disagreeable. The problem (as I see it) is that people who favor the change seem to be trying to use the specifics of this case to justify it -- but my point is that special cases aren't special enough to break the rules. And, that the rules shouldn't be changed to majority wins, if they think it's 'obviously' a bug. (Aside from all that, I also couldn't think of any milder examples of a popular, yet controversial change at that particular moment.) ___ 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby wrote: At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote: Phillip J. Eby schrieb: 2. Add an optional flag argument to enable the new behavior How would that help backwards compatibility? All existing calls to splitext() would work the same way they've done for several years, and the documentation would now make it obvious to new users of the function that there's a choice about how to handle dotfiles. Heck, we could throw in another optional argument to strip multiple extensions like .tar.gz. That may actually be a genuinely useful approach: splitext(name, ignore_leading_dot=False, all_ext=False) Split the extension from a pathname. Returns (root, ext). By default, the extension is all characters from the last dot to the end of the string. ext will be empty if there are no dots in the name and root will be empty if the characters starts with a single dot and that is the only dot in the name. If ignore_leading_dot=True, then a leading dot is always considered part of root, and is ignored when determining the extension. root will never be empty in this case. If all_ext=True, the extension is all characters from the first dot to the end. For that matter, the documentation should address the issue that no matter what options you use, you may *still* end up with unexpected results, for files like Release 1.2, due to the fuzzy nature of the concept of a file extension on modern OSes. Not sure what can be done about that... although such filenames are likely a big reason why grabbing 'all extensions' will typically be a bad idea. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] Proposal to revert r54204 (splitext change)
Steve Holden schrieb: Somebody has pointed out that it is fairly easy to write a wrapper around splitext that explicitly produces the old behavior on all versions, or the new behavior on all versions, depending on what precisely is desired. Users that have coded for a specific behavior will have to write a wrapper - whether they explicitly code for the old behavior or the new one. How is forcing people to write such a wrapper better than providing an optional argument (defaulting to current behavior) to specify the behavior they want? If they pass the flag to the function, the code will stop running on 2.5 and earlier. This is worse than having code that works on all versions. This is also whz I wondered how the flag helps backwards compatibility: when people add the flag, the code stops working on old versions, so it will *not* be backwards compatible. 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] Proposal to revert r54204 (splitext change)
On 3/16/07, Nick Coghlan [EMAIL PROTECTED] wrote: splitext(name, ignore_leading_dot=False, all_ext=False) +1. ISTM this is a reasonable way to go in the face of our existing backward compatibility issue and the differing definitions of extensions across OS's. Mike ___ 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] Proposal to revert r54204 (splitext change)
On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote: If they pass the flag to the function, the code will stop running on 2.5 and earlier. This is worse than having code that works on all versions. This is also whz I wondered how the flag helps backwards compatibility: when people add the flag, the code stops working on old versions, so it will *not* be backwards compatible. I don't understand. Under Nick's proposal, calling splitext with no keyword parameters results in the exact behavior we have today, so it's obviously backward compatible. If you use a keyword parameter, you're using a new feature implemented in 2.6, so there is no expectation of backward compatibility unless and until the keyword parameters are backported. Mike ___ 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] Proposal to revert r54204 (splitext change)
Paul Moore writes: On 16/03/07, Phillip J. Eby [EMAIL PROTECTED] wrote: What's *actually* under dispute here is whether it's acceptable to classify this perfectly useful-as-is behavior, that was documented and tested in released versions of Python for several years (with patches to change its behavior explicitly rejected in the past), as a bug. Just to put this into context, the word bug is probably not the best to use here. The orignal behaviour was described as a bug, certainly, but that's not how the change has been treated. [...] Rather, the change is being treated as a behaviour change (which it is) and submitted for a *feature* release (2.6). Very well put, and the main point. Whether the behaviour change is good, reasonable, acceptable - that's the question here. (And one on which I don't have an opinion!) That definition of the question is open-minded of you. However, Phillip's point remains valid. Eg, Martin's clear preference for not changing API and mild resistance to a warning suggests that the design of this change is strongly influenced by the feeling that current behavior is a bug. I think that's inappropriate. Note that Phillip (and glyph, AIUI) is not opposing a behavior change in Python; he simply wants the current API to keep the same spec (here I mean the docstring). I have seen many discussions like this one on various Emacs-related lists, and I would not use a mild phrase like the word 'bug' is probably not the best to use here. In my experience, use of the word bug to describe behavior that is consistent with all documented specifications is usually a political play. When such a change is described as a feature, the majority of programmers who haven't careful studied the spec will say I thought it already does that now, and I wish it would. When it is described as a bugfix, that changes to I thought it already does that now, so I demand that it do so. (All this is much less true of Python, but the dynamic can be seen here, too.) That is, even in a feature release backward compatibility is very important, it's just not paramount any more. If you describe it as a new feature, then people are very likely to accept the admittedly expensive process of defining a new API for the improved behavior, and where necessary deprecating the old behavior, and finally removing it. If you describe it as a bugfix, many will not. My opinion is that this shift of atmosphere leads to bad decisions. In cases where behavior conforms to spec, the process of define new API -- deprecate -- remove, though expensive, is almost always a good investment. It both lowers compatibility costs, and makes them much more plan-able. These costs are both large and easy to underestimate, so that's a very good thing. ___ 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] Proposal to revert r54204 (splitext change)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 16, 2007, at 3:30 PM, Mike Krell wrote: On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote: If they pass the flag to the function, the code will stop running on 2.5 and earlier. This is worse than having code that works on all versions. This is also whz I wondered how the flag helps backwards compatibility: when people add the flag, the code stops working on old versions, so it will *not* be backwards compatible. I don't understand. Under Nick's proposal, calling splitext with no keyword parameters results in the exact behavior we have today, so it's obviously backward compatible. If you use a keyword parameter, you're using a new feature implemented in 2.6, so there is no expectation of backward compatibility unless and until the keyword parameters are backported. Let's remember the lessons of True and False in Python 2.2.1. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRfr04nEjvBPtnXfVAQKxXgP9GmIx6OANec+aGsT9X9KoJsWLM+RGYrjB RuDy5uxIbxfZg0logFzvTH4iLCnjJzfhhFrc8V9RjDf7I8vubM+caaEvZBDRoabW bNO6L4IA1zGKjmKYhVhnLkRFNk3iEHwvG9Fa4ahqcCaeS99IYBejwtZ0Sqd171dL ZQnUFBT5vBU= =NlKx -END 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] Proposal to revert r54204 (splitext change)
Mike Krell schrieb: On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote: If they pass the flag to the function, the code will stop running on 2.5 and earlier. This is worse than having code that works on all versions. This is also whz I wondered how the flag helps backwards compatibility: when people add the flag, the code stops working on old versions, so it will *not* be backwards compatible. I don't understand. Under Nick's proposal, calling splitext with no keyword parameters results in the exact behavior we have today, so it's obviously backward compatible. If you use a keyword parameter, you're using a new feature implemented in 2.6, so there is no expectation of backward compatibility unless and until the keyword parameters are backported. Assuming the current behavior is a bug (which I still believe to be the case), in order to actually make use of the bug fix, you have to pass the parameter. This will make your code break on old versions. 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] Proposal to revert r54204 (splitext change)
Nick Coghlan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That may actually be a genuinely useful approach: splitext(name, ignore_leading_dot=False, all_ext=False) Split the extension from a pathname. Returns (root, ext). By default, the extension is all characters from the last dot to the end of the string. ext will be empty if there are no dots in the name and root will be empty if the characters starts with a single dot and that is the only dot in the name. If ignore_leading_dot=True, then a leading dot is always considered part of root, and is ignored when determining the extension. root will never be empty in this case. If all_ext=True, the extension is all characters from the first dot to the end. = 'first dot' = 'first non-ignored dot' in case both options are true. In the long run (in 3.0), I think ignore_leading_dot should default to True rather than False since I think that is what more people will want. However, I believe the 2-to-3 converter could remove 'ignore_leading_dot=True' and insert 'ignore_leading_dot=False' as needed. 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] Proposal to revert r54204 (splitext change)
On 03/16/2007 05:43 PM, Nick Coghlan wrote: -- Sjoerd Mullender Phillip J. Eby wrote: At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote: Phillip J. Eby schrieb: 2. Add an optional flag argument to enable the new behavior How would that help backwards compatibility? All existing calls to splitext() would work the same way they've done for several years, and the documentation would now make it obvious to new users of the function that there's a choice about how to handle dotfiles. Heck, we could throw in another optional argument to strip multiple extensions like .tar.gz. That may actually be a genuinely useful approach: splitext(name, ignore_leading_dot=False, all_ext=False) Split the extension from a pathname. Returns (root, ext). By default, the extension is all characters from the last dot to the Presumably that would be the last dot after the last separator (i.e. / and/or \). I would not expect ext to ever contain a separator. end of the string. ext will be empty if there are no dots in the name and root will be empty if the characters starts with a single dot and that is the only dot in the name. If ignore_leading_dot=True, then a leading dot is always considered part of root, and is ignored when determining the extension. root will never be empty in this case. If all_ext=True, the extension is all characters from the first dot to the end. For that matter, the documentation should address the issue that no matter what options you use, you may *still* end up with unexpected results, for files like Release 1.2, due to the fuzzy nature of the concept of a file extension on modern OSes. Not sure what can be done about that... although such filenames are likely a big reason why grabbing 'all extensions' will typically be a bad idea. Regards, Nick. -- Sjoerd Mullender ___ 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] Proposal to revert r54204 (splitext change)
On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Assuming the current behavior is a bug (which I still believe to be the case), in order to actually make use of the bug fix, you have to pass the parameter. This will make your code break on old versions. But, that's a GOOD thing. If you don't use the flags approach, your code will silently fail on the old versions. Pat ___ 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] Proposal to revert r54204 (splitext change)
Patrick Maupin schrieb: On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Assuming the current behavior is a bug (which I still believe to be the case), in order to actually make use of the bug fix, you have to pass the parameter. This will make your code break on old versions. But, that's a GOOD thing. If you don't use the flags approach, your code will silently fail on the old versions. Whether it will fail depends on the code. It will silently behave differently, but it will not (necessarily) fail. 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] Proposal to revert r54204 (splitext change)
On 15 Mar, 11:34 pm, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: However, the decision was a bad one regardless of the existing policy, and sets a bad precedent while we are discussing this policy. I could be wrong, but I think it would be reasonable to assume that if Martin strongly supports such a change, Martin would oppose a policy which would strictly forbid such changes, and it is just such a policy that Python needs. I still can't guess what policy you have in mind, so I can't object to it :-) I may accept a policy that rejects this change, but allows another change to fix the problem. I would oppose a policy that causes this bug to be unfixable forever. Well, there's *also* the fact that I strongly disagree that this is a bug, but I don't know that I could codify that in a policy. Hence the parallel discussion. However, I do apologize for obliquely referring to this thing I'm working on without showing a work in progress. It's just that different parts of the policy will rely on each other, and I don't want to get bogged down talking about individual details which will be dealt with in the final rev. That, and I am trying to integrate feedback from the ongoing discussion... ___ 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] Proposal to revert r54204 (splitext change)
That may actually be a genuinely useful approach: splitext(name, ignore_leading_dot=False, all_ext=False) ... that's perfect. I updated my patch to do it that way! :) --S ___ 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] Proposal to revert r54204 (splitext change)
Mike Krell wrote: I said the name .emacs was used as an example. For that matter, the name a.txt was also used as an example. The use cases are real. So does your application create any file names that have a single dot at the beginning? -- Greg ___ 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] Proposal to revert r54204 (splitext change)
On 3/16/07, Greg Ewing [EMAIL PROTECTED] wrote: Mike Krell wrote: I said the name .emacs was used as an example. For that matter, the name a.txt was also used as an example. The use cases are real. So does your application create any file names that have a single dot at the beginning? Yes. How many more times would you like me to answer this question? Just in case you'd like me to answer it three more times, here are the answers: Yes, yes, and yes. Mike ___ 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] Proposal to revert r54204 (splitext change)
Martin v. Löwis writes: Phillip J. Eby schrieb: Some other options: 1. Deprecate splitext() and remove it in 3.0 How would that help the problem? Isn't it useful to have a function that strips off the extension? No. It's useful to have a function that performs a well-specified algorithm on file names containing dots, but (except on certain file systems such as FAT) the extension does not uniquely exist. People and programs will disagree on the decomposition of file.tar.gz. On FAT file systems, it's defined incorrectly according to you. As IIRC glyph pointed out, if you're going to include either shell semantics (dotfiles) or content semantics (file type for a generic open anything command) in the specification of file extension, what I prefer is guess_file_type(), not splitext(). A more emphatic way to express this is, I would never use a library function whose semantics were defined as split a file name into the base and the extension because I would expect gratuitous backward incompatibility of the kind you have introduced (and it could go either way).[1] N.B. Backward compatibility can be defined by reference to an implementation (often denigrated as bug compatibility) or to a specification. This change is backward incompatible with respect to the implementation and the docstring specification. I would personally prefer the 2.4 definition of splitext(), merely because it's so simple. I would (absent this long discussionwink) always have to look up the treatment of dotfiles, anyway, and my own only use (in one function, 3 calls) of splitext is precisely def versioned_file_name (filename, version): base, ext = splitext (filename) return %s.%s%s % (base,version,ext) 2. Add an optional flag argument to enable the new behavior How would that help backwards compatibility? As Steve Holden points out, by preserving it if the flag is omitted. That is so obvious that I think merely asking that question is perverse. You seem to be granting official status to the unwritten and controversial intuitive specification that many programmers guess from the name. That is way out of line with any sane interpretation of compatibility with past versions of Python. I think all of the advocates of changing the function rather than the library reference are being very short-sighted. I agree with you that looking at this one case, it will be very expensive for all those who have (currently broken) code that expects splitext to treat dotfiles as having a base that starts with a dot (rather than an empty base) to change to use a new function. (I think the realistic solution for them is monkeypatching.) But using this to justify the backward incompatibility is like thinking you can eat just one potato chip, and so not go off your diet. The incompatibility costs of applying this greedy algorithm to all cases where the Python specification differs from common intuition will not merely be very expensive, they will be astronomically so -- but practically invisible because the cost will be in terms of developers who refuse to upgrade their applications to take advantage of new features of Python because their own library code gets broken. The only path I can see where it makes sense to make this change is as an appendix to glyph's PEP. The appendix could give a list of such changes and the decision, relative to some base version. Or it could specify that contributions to 2.6 can be backward incompatible, but not afterward. In that case the promise to eat only this one potato chip becomes credible. I prefer the explicit list approach, that would force the discussion to occur in one place, so that both proponents and opponents of each change would be made aware of how many such changes are being made. Footnotes: [1] ___ 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] Proposal to revert r54204 (splitext change)
Mike Krell wrote: On 3/16/07, Greg Ewing [EMAIL PROTECTED] wrote: Mike Krell wrote: I said the name .emacs was used as an example. For that matter, the name a.txt was also used as an example. The use cases are real. So does your application create any file names that have a single dot at the beginning? Yes. How many more times would you like me to answer this question? Just in case you'd like me to answer it three more times, here are the answers: Yes, yes, and yes. So that would be a yes, then. Perhaps you'd like to remind me that backward compatibilty includes the necessity to run new programs on old versions of Python, too? Then I can stop wasting everyone's time. Even though I am no fonder of code breakage than I was. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ 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] Proposal to revert r54204 (splitext change)
On 3/16/07, Steve Holden [EMAIL PROTECTED] wrote: Perhaps you'd like to remind me that backward compatibilty includes the necessity to run new programs on old versions of Python, too? Ahh, but you see, new programs are the easy part. You actually have at least four choices of different levels of backward compatibility: 1) If you are absolutely sure that the code in your program will never be used to work with filenames with leading dots, you are already finished! (Note that this goal is much easier to achieve if you don't release the source, or at least write it so badly that nobody will want to reuse the code.) 2) If you think that most users of your program won't use filenames with leading dots, and you don't plan on supporting it after a year or so, just make sure it works with 2.5. 3) Conversely, if you're not that bothered about leading dots, and don't think you'll have all the bugs out of your program for a year or so anyway, just wait for 2.6. (All the cool potential users of your program will be on the bleeding edge, anyway.) 4) Finally, if you're one of those Luddite sticklers who wants to try to ruin everybody's job security by writing code that works right now and doesn't need to be touched later, just write your own version of this function. I would have suggested that you could reuse the underlying functionality in conjunction with a version check, but it has been pointed out that the existence of tests and docstrings which perfectly match the code is no impediment to change, so Philip might get mad enough to change it back for 3.1, and then your version check would be obsolete. Then I can stop wasting everyone's time. Even though I am no fonder of code breakage than I was. Fortunately, for new code (at least for this particular change!), you don't have to worry about breakage. I'm sure this discussion has been so indelibly etched into your brain that you won't forget to check your filename management functions very carefully. Sorry, were you being sarcastic? I didn't realize that. Or am I prevaricating again? Regards, Pat ___ 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] Proposal to revert r54204 (splitext change)
On 2007-03-15 07:45, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
And yet, that incorrect behavior was clearly intended by the author(s)
of the code, test, and docstrings.
As it happens, Guido wrote that code (16 years ago) and the docstring (9
years ago), in the case of the posixpath module at least.
I don't find it that clear that it was the intention, AFAICT, it could
have been an accident also. Guido added the doc strings as a
contribution from Charles G. Waldman; he may just have documented the
implemented behavior.
In r4493, Sjoerd Mullender changed splitext (in an incompatible way)
so that it would split off only the last extension, before, foo.tar.gz
would be split into 'foo', '.tar.gz'. So it's clear that the intention
was always to split off the extension, whether or not the behavior
on dotfiles was considered I cannot tell.
As for Doc/lib, in r6524 Guido changed it to document the actual
behavior, from
the last component of \var{root} contains no periods,
and \var{ext} is empty or begins with a period.
to
and \var{ext} is empty or begins with a period and contains
at most one period.
So it seems the original (Guido's) intention was that it splits
of all extensions; Sjoerd then changed it to split off only the
last extension.
Whatever the intention was or has been: the term extension
itself is not well-defined, so there's no obvious right way
to implement an API that splits off an extension.
E.g. in some cases, .tar.gz is considered an extension, in others,
the .gz part is just a transfer encoding and .tar the extension.
Then you have .tgz which is a bit of both. It also depends on the
platform, e.g. on Windows, only the very last part of a filename
is used as extension by the OS to determine the (MIME) type of
a file.
As always, it's best to just right your own application-specific
code to get defined behavior.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 15 2007)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
___
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] Proposal to revert r54204 (splitext change)
At 07:45 AM 3/15/2007 +0100, Martin v. Löwis wrote: I apparently took the same position that you now take back then, whereas I'm now leaning towards (or going beyond) the position Tim had back then, who wrote BTW, if it *weren't* for the code breakage, I'd be in favor of doing this. If it weren't for the code breakage, I'd be in favor too. That's not the point. The point is that how can Python be stable as a language if precedents can be reversed without a migration plan, just because somebody changes their mind? In another five years, will you change your mind again, and decide to put this back the way it was? Speaking as a business person, that seems to me... unwise. When I found out that this change had been checked in despite all the opposition, my gut reaction was, I guess I can't rely on Python any more, despite 10 years of working with it, developing open source software with it, and contributing to its development. Because from a *business* perspective, this sort of flip-flopping means that moving from one minor Python version to another is potentially *very* costly. The process of having warnings at least ensures that I can *discover* whether my programs depend on some behavior that has changed - rather than having something that used to work and now doesn't. I now believe that this should be done *despite* having been documented and tested (which, as you can see, was documented and tested only match the implemented behavior). That it keeps popping up is proof that the old behavior is deemed incorrect by many people. But as you are so fond of pointing out, there is no many people. There are only individual people. That a majority want it one way, means that there is a minority who want it another. If next year, it becomes more popular to have it the other way, will we switch again? If a majority of people want braces and required type declarations, will we add them? After all, there is *substantial* support for some proposals along those lines! Yet, one of the appeals of Python is that it has some sense of what is right or wrong, and some explanation for that rightness or wrongness that doesn't change with the ebb and flow of popular opinion and the current population of a mailing list. IMO, Python is not -- or at least should not be -- a popularity contest. So reject it, or propose to add a new API. Neither is a solution. Rejecting it means it will keep popping up forever. Like requests to remove whitespace sensitivity and add braces? That a request may keep popping up forever is not an argument for changing it NOW. As Tim put it, Never is often better than *right* now, and it seems to me that this is *exactly* the sort of change for which that saying was coined. The amount of Python code yet to be written is hopefully larger than the code already written (paraphrasing Guido), so in the long run, it should show the right behavior, not the historical one. Sure - but by that argument, the amount of code that will be written in 3.0 or 3.1 is larger still, and if this behavior's been mostly okay for 9+ years, then fixing it in a year or two should be quite prompt, if you want to look at the historical scale. In any case, my main concern about this change isn't whether it's right or wrong -- it's about whether Python provides a stable platform for software development with reasonable migration paths. *This* change won't actually hurt *me* -- but what will the next change be? Must everyone who wants some form of stability maintain a constant watch over Python's source changes? I gather that your answer is yes, and that's what disturbs me here. ___ 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby schrieb: If it weren't for the code breakage, I'd be in favor too. That's not the point. The point is that how can Python be stable as a language if precedents can be reversed without a migration plan, just because somebody changes their mind? In another five years, will you change your mind again, and decide to put this back the way it was? I'm still wondering what policy you think I have violated. If we both agree that the old behavior was erroneous, then I cannot understand why you want to see the patch reverted. Nobody has so far proposed any alternative fix (not even as a specification, let alone as a specific patch - just with some hinting), and the majority of the people polled thought that it ought to be fixed. The process of having warnings at least ensures that I can *discover* whether my programs depend on some behavior that has changed - rather than having something that used to work and now doesn't. So you would agree to the change if a warning was generated at run-time? Notice that there is already a warning there: the documentation clearly states that the behavior has changed, and, of course, Misc/NEWS lists it as changed behavior. So you can certainly discover *now* that the behavior has changed: read the documentation. If you want to discover it without reading documentation, we can discuss that. But as you are so fond of pointing out, there is no many people. There are only individual people. That a majority want it one way, means that there is a minority who want it another. If next year, it becomes more popular to have it the other way, will we switch again? This is highly theoretical. If a majority of people want braces and required type declarations, will we add them? PEP 3099 explicitly rules out the introduction of braces. As for type declarations: it would require a PEP, being a major feature. It then depends on the details. PEP 245 was rejected by BDFL pronouncement. This is how things are ultimately decided: by BDFL pronouncement. Yet, one of the appeals of Python is that it has some sense of what is right or wrong, and some explanation for that rightness or wrongness that doesn't change with the ebb and flow of popular opinion and the current population of a mailing list. In this specific case, it seems that people had agree on right for a long time, and had just accepted that the current implementation is wrong. You also agree to that, and many other long-time Python contributors have agreed. So as long as those people are around, it is unlikely that they change their minds again on this specific question. So reject it, or propose to add a new API. Neither is a solution. Rejecting it means it will keep popping up forever. Like requests to remove whitespace sensitivity and add braces? No, unlike that. See above, plus the people contributing to Python believe that the current behavior is right (although the view on using tabs-vs-spaces has changed over time). In this case it's different: all long-time contributors seem to agree that the new behavior is the desirable one, on a green field. In any case, my main concern about this change isn't whether it's right or wrong -- it's about whether Python provides a stable platform for software development with reasonable migration paths. *This* change won't actually hurt *me* -- but what will the next change be? Must everyone who wants some form of stability maintain a constant watch over Python's source changes? I gather that your answer is yes, and that's what disturbs me here. No. I firmly believe that even with this change, Python provides some form of stability. All the alternatives that had been proposed, except for the never variant, provide less stability. This is the most stable patch to solve the problem that I could think of. 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby wrote: At 07:45 AM 3/15/2007 +0100, Martin v. Löwis wrote: I apparently took the same position that you now take back then, whereas I'm now leaning towards (or going beyond) the position Tim had back then, who wrote BTW, if it *weren't* for the code breakage, I'd be in favor of doing this. If it weren't for the code breakage, I'd be in favor too. That's not the point. The point is that how can Python be stable as a language if precedents can be reversed without a migration plan, just because somebody changes their mind? In another five years, will you change your mind again, and decide to put this back the way it was? Speaking as a business person, that seems to me... unwise. When I found out that this change had been checked in despite all the opposition, my gut reaction was, I guess I can't rely on Python any more, despite 10 years of working with it, developing open source software with it, and contributing to its development. Because from a *business* perspective, this sort of flip-flopping means that moving from one minor Python version to another is potentially *very* costly. The process of having warnings at least ensures that I can *discover* whether my programs depend on some behavior that has changed - rather than having something that used to work and now doesn't. I now believe that this should be done *despite* having been documented and tested (which, as you can see, was documented and tested only match the implemented behavior). That it keeps popping up is proof that the old behavior is deemed incorrect by many people. But as you are so fond of pointing out, there is no many people. There are only individual people. That a majority want it one way, means that there is a minority who want it another. If next year, it becomes more popular to have it the other way, will we switch again? If a majority of people want braces and required type declarations, will we add them? After all, there is *substantial* support for some proposals along those lines! Yet, one of the appeals of Python is that it has some sense of what is right or wrong, and some explanation for that rightness or wrongness that doesn't change with the ebb and flow of popular opinion and the current population of a mailing list. IMO, Python is not -- or at least should not be -- a popularity contest. So reject it, or propose to add a new API. Neither is a solution. Rejecting it means it will keep popping up forever. Like requests to remove whitespace sensitivity and add braces? That a request may keep popping up forever is not an argument for changing it NOW. As Tim put it, Never is often better than *right* now, and it seems to me that this is *exactly* the sort of change for which that saying was coined. The amount of Python code yet to be written is hopefully larger than the code already written (paraphrasing Guido), so in the long run, it should show the right behavior, not the historical one. Sure - but by that argument, the amount of code that will be written in 3.0 or 3.1 is larger still, and if this behavior's been mostly okay for 9+ years, then fixing it in a year or two should be quite prompt, if you want to look at the historical scale. In any case, my main concern about this change isn't whether it's right or wrong -- it's about whether Python provides a stable platform for software development with reasonable migration paths. *This* change won't actually hurt *me* -- but what will the next change be? Must everyone who wants some form of stability maintain a constant watch over Python's source changes? I gather that your answer is yes, and that's what disturbs me here. The impact of this one little change certainly isn't the only issue at stake here. But as Mr. Creosote knows, even one little wafer thin change can lead to a chaotic transformation. Since 2.0 serious efforts have been made to maintain, and even promote, the stability and backwards compatibility of Python. This has benefited the language. This particular change looks like gratuitous breakage, no matter how sound the reasons for it, and putting it in to 2.6 with 3.0 just around the corner (though not for production purposes) is guaranteed to upset some people and cause adverse reaction. Now, you might feel (as Guido does) that it doesn't matter what people write in their blogs, but I personally want people to perceive Python as a language whose development is carefully managed. Consequently I am disturbed when a change of this nature is made and it becomes apparent that there is no consensus for it. This is not prevarication, it's a serious discussion about how such issues should be managed. The current glaring lack is of a sound decision-making process. Such breakage-inducing change should be reserved for major versions (as was the fix to the socket addressing wart). regards Steve
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
Steve Holden schrieb: This is not prevarication, it's a serious discussion about how such issues should be managed. The current glaring lack is of a sound decision-making process. Such breakage-inducing change should be reserved for major versions (as was the fix to the socket addressing wart). Please take a look at Misc/NEWS and review all changes that had been made since 2.5 to find out what other changes are breakage-inducing. 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] Proposal to revert r54204 (splitext change)
This particular change looks like gratuitous breakage, no matter how sound the reasons for it, and putting it in to 2.6 with 3.0 just around the corner (though not for production purposes) is guaranteed to upset some people and cause adverse reaction. This is not prevarication, it's a serious discussion about how such issues should be managed. The current glaring lack is of a sound decision-making process. Such breakage-inducing change should be reserved for major versions (as was the fix to the socket addressing wart). I just like to point out that I disagree with this classification. The change is not gratuitous breakage (it's neither gratuitous, nor is it breakage), nor is it breakage-inducing. 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] Proposal to revert r54204 (splitext change)
On 05:51 pm, [EMAIL PROTECTED] wrote: At 07:45 AM 3/15/2007 +0100, Martin v. L�wis wrote: I apparently took the same position that you now take back then, whereas I'm now leaning towards (or going beyond) the position Tim had back then, who wrote BTW, if it *weren't* for the code breakage, I'd be in favor of doing this. If it weren't for the code breakage, I'd be in favor too. That's not the point. The point is that how can Python be stable as a language if precedents can be reversed without a migration plan, just because somebody changes their mind? In another five years, will you change your mind again, and decide to put this back the way it was? Hear, hear. Python is _not_ stable as a language. I have Java programs that I wrote almost ten years ago which still run perfectly on the latest runtime. There is python software I wrote two years ago which doesn't work right on 2.5, and some of the Python stuff contemporary with that Java code won't even import. Speaking as a business person, that seems to me... unwise. When I found out that this change had been checked in despite all the opposition, my gut reaction was, I guess I can't rely on Python any more, despite 10 years of working with it, developing open source software with it, and contributing to its development. Because from a *business* perspective, this sort of flip-flopping means that moving from one minor Python version to another is potentially *very* costly. And indeed it is. Python's advantages in terms of rapidity of development have, thus far, made up the difference for me, but it is threatening to become a close thing. This is a severe problem and something needs to be done about it. But as you are so fond of pointing out, there is no many people. There are only individual people. That a majority want it one way, means that there is a minority who want it another. If next year, it becomes more popular to have it the other way, will we switch again? If a majority of people want braces and required type declarations, will we add them? And, in fact, there is not even a majority. There is a *perception* of a majority. There isn't even a *perception* of a majority of Python users, but a perception of a majority of python-dev readers, who are almost by definition less risk-averse when it comes to language change than anyone else! If we actually care about majorities, let's set up a voting application and allow Python users to vote on each and every feature, and publicize it each time such a debate comes up. Here, I'll get it started: http://jyte.com/cl/python-should-have-a-strict-backward-compatibility- policy-to-guide-its-development According to that highly scientific study, at this point in time, Nobody disagrees :). (One in favor, zero against.) ___ 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] Proposal to revert r54204 (splitext change)
On 3/15/07, Martin v. Löwis [EMAIL PROTECTED] wrote: ... the majority of the people polled thought that it ought to be fixed. Personally, I didn't respond to your poll because I didn't think this particular issue would come down to a silly head count of self-selecting responders. When I first needed to use splitext in my code, I tested the relevant corner case in question at the interactive prompt. I also read the docstring which explicitly documented the behavior. I then wrote my code accordingly. Knowing that this was well-defined and documented behavior and having followed this list during previous backward compatibility discussions, I knew that there was no way your proposed patch would make it into a minor release because many long-time active developers would rightfully point out that it gratuitously breaks code. In your radical departure from the common-sense approach to code-breaking changes that typically prevails here, you proved me wrong. So now I'm speaking up. FWIW, I agree completely with PJE's and glyph's remarks with respect to expectations of stability, especially in a minor release. Sorry, updating the NEWS file isn't good enough, because as has been amply demonstrated here, many people cannot be bothered to read the documentation. +1 on reverting the patch and not punishing those users who bothered to the documentation or test the corner cases themselves. Mike ___ 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] Proposal to revert r54204 (splitext change)
Mike Krell schrieb: When I first needed to use splitext in my code, I tested the relevant corner case in question at the interactive prompt. I also read the docstring which explicitly documented the behavior. I then wrote my code accordingly. Can you show us the relevant fragment of your code? 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] Proposal to revert r54204 (splitext change)
Mike Krell schrieb: FWIW, I agree completely with PJE's and glyph's remarks with respect to expectations of stability, especially in a minor release. Not sure what you mean by minor release. The change isn't proposed for the next bug fix release (2.5.1), but for the next major release (2.6). See PEP 6. 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The process of having warnings at least ensures that I can *discover* whether my programs depend on some behavior that has changed - rather than having something that used to work and now doesn't. I am not familiar with the warning system, but it seems plausible that one could add to the end of .splitext (before it returns) an optional warning something like if not ext and base[0] == '.': warn(Before 2.6, this would have returned (%s,%s) instead of (%s,%s) % (ext, base, base, ext)) where base and ext have the obvious contents. Is this what you want? 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] Proposal to revert r54204 (splitext change)
On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 05:51 pm, [EMAIL PROTECTED] wrote: At 07:45 AM 3/15/2007 +0100, Martin v. Löwis wrote: I apparently took the same position that you now take back then, whereas I'm now leaning towards (or going beyond) the position Tim had back then, who wrote BTW, if it *weren't* for the code breakage, I'd be in favor of doing this. If it weren't for the code breakage, I'd be in favor too. That's not the point. The point is that how can Python be stable as a language if precedents can be reversed without a migration plan, just because somebody changes their mind? In another five years, will you change your mind again, and decide to put this back the way it was? Hear, hear. Python is _not_ stable as a language. I have Java programs that I wrote almost ten years ago which still run perfectly on the latest runtime. There is python software I wrote two years ago which doesn't work right on 2.5, and some of the Python stuff contemporary with that Java code won't even import. I think the problem has less to do with bug fixing than with lack of any clear specifications or documentation about what developers can depend on.You could probably make a case that any change that doesn't fix a crash bug is likely to cause some particular program to behave differently. Take bug 1504333 which lead to a change in sgmllib behavior for angle brackets in quoted attribute values. Did the sgmllib documentation explain that the fixed behavior was incorrect? Might a programmer working with sgmllib have written code that depended on this bug? Do you object to this bug fix? For many of these bugs, some people will have written code against the documentation and some people against the implementation or behavior. (In this case, the documentation is vague or conflicting.) I don't think I know how to balance the important of these two classes of users. Some code is going to break the first time they run into the under-specific edge case, some code is going to break when the specification and implementation are clarified. You have to weigh which you think is more likely and which will benefit users the most. I think everyone wants to do the right thing by Python's users, but it's not clear what that right thing is. Speaking as a business person, that seems to me... unwise. When I found out that this change had been checked in despite all the opposition, my gut reaction was, I guess I can't rely on Python any more, despite 10 years of working with it, developing open source software with it, and contributing to its development. Because from a *business* perspective, this sort of flip-flopping means that moving from one minor Python version to another is potentially *very* costly. And indeed it is. Python's advantages in terms of rapidity of development have, thus far, made up the difference for me, but it is threatening to become a close thing. This is a severe problem and something needs to be done about it. Could you point out a few such programs that people on python-dev can look at? I think it would be useful to gather some data about the kind of migration pains real users are having. I believe Martin and others are trying to do the right thing. Real data is more likely to convince them than passionate arguments on python-dev. But as you are so fond of pointing out, there is no many people. There are only individual people. That a majority want it one way, means that there is a minority who want it another. If next year, it becomes more popular to have it the other way, will we switch again? If a majority of people want braces and required type declarations, will we add them? And, in fact, there is not even a majority. There is a *perception* of a majority. There isn't even a *perception* of a majority of Python users, but a perception of a majority of python-dev readers, who are almost by definition less risk-averse when it comes to language change than anyone else! I think you missed the point here. The hypothetical question was not about any particular majority, but rather that regardless of which group you poll, the majority decision may not be the right one. Even a majority of Twised users :-). Jeremy If we actually care about majorities, let's set up a voting application and allow Python users to vote on each and every feature, and publicize it each time such a debate comes up. Here, I'll get it started: http://jyte.com/cl/python-should-have-a-strict-backward-compatibility-policy-to-guide-its-development According to that highly scientific study, at this point in time, Nobody disagrees :). (One in favor, zero against.) ___ 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/jeremy%40alum.mit.edu
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
On 3/15/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Can you show us the relevant fragment of your code?
Sure:
for f in files:
try:
(root, ext) = os.path.splitext(f)
os.rename(f, '%s.%s%s' % (root, index, ext))
except OSError:
die('renaming %s failed' % f)
Background:
This is a little utility that runs on windows that archives arbitrary
files. index is an integer.
For index == 1, I want a.txt to be renamed to a.1.txt, and I want
.emacs to be renamed to .1.emacs, thus preserving the extensions.
Under the new patch, the second file would be renamed to .emacs.1,
gratuitously breaking the extension preservation.
Mike
___
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] Proposal to revert r54204 (splitext change)
On 08:21 pm, [EMAIL PROTECTED] wrote: Mike Krell schrieb: FWIW, I agree completely with PJE's and glyph's remarks with respect to expectations of stability, especially in a minor release. Not sure what you mean by minor release. The change isn't proposed for the next bug fix release (2.5.1), but for the next major release (2.6). See PEP 6. Common parlance for the parts of a version number is: major.minor.micro See: http://twistedmatrix.com/documents/current/api/twisted.python.versions.Version.html#__init__ Changing this terminology about Python releases to be more consistent with other projects would be a a subtle, but good shift towards a generally better attitude of the expectations of minor releases. ___ 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] Proposal to revert r54204 (splitext change)
Martin v. Löwis schrieb: Steve Holden schrieb: This is not prevarication, it's a serious discussion about how such issues should be managed. The current glaring lack is of a sound decision-making process. Such breakage-inducing change should be reserved for major versions (as was the fix to the socket addressing wart). Please take a look at Misc/NEWS and review all changes that had been made since 2.5 to find out what other changes are breakage-inducing. For example, I committed a fix for urllib that made it raise IOError instead of an AttributeError (which wasn't explicitly raised, of course) if a certain error condition occurs. This is changed behavior too, but if we are to postpone all these fixes to 3.0, we won't have half of the fixes in Python 2.6 that are there now. Georg ___ 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] Proposal to revert r54204 (splitext change)
Martin v. Löwis schrieb: The process of having warnings at least ensures that I can *discover* whether my programs depend on some behavior that has changed - rather than having something that used to work and now doesn't. So you would agree to the change if a warning was generated at run-time? Notice that there is already a warning there: the documentation clearly states that the behavior has changed, and, of course, Misc/NEWS lists it as changed behavior. As a sidenote, this item should be included in the 2.6 What's new's porting section. Perhaps it would be a good policy to automatically list potentially breaking fixes there instead of rolling off that task to Andrew. Georg ___ 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] Proposal to revert r54204 (splitext change)
On 3/15/07, Martin v. Löwis [EMAIL PROTECTED] wrote: This particular change looks like gratuitous breakage, no matter how sound the reasons for it, and putting it in to 2.6 with 3.0 just around the corner (though not for production purposes) is guaranteed to upset some people and cause adverse reaction. This is not prevarication, it's a serious discussion about how such issues should be managed. The current glaring lack is of a sound decision-making process. Such breakage-inducing change should be reserved for major versions (as was the fix to the socket addressing wart). I just like to point out that I disagree with this classification. The change is not gratuitous breakage (it's neither gratuitous, nor is it breakage), nor is it breakage-inducing. First off, I should say I totally agree with Martin's thinking in this whole matter. If I had been in his situation there is a good chance I would have done what he did based on prior history of when underspecified stuff has what could considered poor behaviour. But the key point I want to get across is people should not being getting mad at Martin. The people who are getting all bent out of shape over this should be upset at python-dev as a whole for not having a clear policy on this sort of thing. Martin just happened to be the guy who made a change that sparked this and he is explaining his thinking behind it (which also happens to mirror my thinking on this whole situation). It could have easily been someone else. But since Martin does so much work clearing out patches (and we all owe Martin and everyone else who consistently tries to close bugs and patches a HUGE thank you). I am sorry it happened to be Martin, but I also think he has done a great job keeping his composure in this as I would have lost my top at by now had I not been ignoring this thread. And I would hope that people are not explicitly mad at Martin (I suspect people aren't). But from my viewpoint people are getting the point of yelling and that is not going to get us anywhere. Bottom line, let's work together as a group to come up with a policy in a civil, positive manner (in a new thread!) and let the result of that decision guide what is done with this fix. Yelling at poor Martin about one patch when we could be spending this effort on trying to discuss what kind of policy we want is not getting us anywhere. -Brett ___ 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] Proposal to revert r54204 (splitext change)
Mike Krell schrieb:
Sure:
for f in files:
try:
(root, ext) = os.path.splitext(f)
os.rename(f, '%s.%s%s' % (root, index, ext))
except OSError:
die('renaming %s failed' % f)
Thanks! Looking more closely, it's not entirely clear where index
comes from - what if you already have a.1.txt. Will you set it
to 2? Will that then produce a.1.2.txt?
This is a little utility that runs on windows that archives arbitrary
files. index is an integer.
For index == 1, I want a.txt to be renamed to a.1.txt, and I want
.emacs to be renamed to .1.emacs, thus preserving the extensions.
Under the new patch, the second file would be renamed to .emacs.1,
gratuitously breaking the extension preservation.
I can see that it breaks the behavior you intended it to have. However,
I disagree that it broke extension preservation. Rather, it *provides*
extension preservation, something that the old code did not do.
I also like to point out that the primary objective of the code
(archive arbitrary files) is still preserved - it still does that,
but in different manner. (disclaimer: I don't fully understand the
index part)
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] Proposal to revert r54204 (splitext change)
For example, I committed a fix for urllib that made it raise IOError instead of an AttributeError (which wasn't explicitly raised, of course) if a certain error condition occurs. This is changed behavior too, but if we are to postpone all these fixes to 3.0, we won't have half of the fixes in Python 2.6 that are there now. There's a big difference between that change and this one; that change is 'loud'. It makes noise. It's raising an exception: that exception will either be handled or will propagate up the stack and be noticed somewhere. I *think* (ahem.. I read minds...) the problem people are having with this particular change is the fact that the behavior of this function is being changed in a way that is completely silent. Code written to expect one kind of result are now getting a different kind of result... instead of having an error thrown, a warning given, or something explicit... it's just different now. And it'd be so easy to do it in a way which wouldn't be silent... just throw out a warning, and defer the actual change until the next release. Expecting people to keep on top of Misc/NEWS and re-read the documentation for every function in their code is a tad unreasonable. I don't personally find it unreasonable for people to ask for a bit more of an extended migration path when changes that are being implemented will cause *silent* changes in behavior. It's been very hard for my company to move from 2.3 to 2.4 as a development platform as it is, which we're just barely doing now... for this reason I'm paying a lot more attention to -dev lately to be prepared for 2.6 and beyond. Not everyone has the time to do that.. there's a lot of messages :) And Misc/NEWS is *huge*. Warnings are a very useful mechanism for semi-painless migrations and upgrades... (And, if I thought it'd have any chance of going in, I'd submit a patch to add a warning and adjust docs/tests/etc... but this issue seems ever so divided...) --S ___ 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] Proposal to revert r54204 (splitext change)
[EMAIL PROTECTED] schrieb: Not sure what you mean by minor release. The change isn't proposed for the next bug fix release (2.5.1), but for the next major release (2.6). See PEP 6. Common parlance for the parts of a version number is: major.minor.micro See: http://twistedmatrix.com/documents/current/api/twisted.python.versions.Version.html#__init__ Changing this terminology about Python releases to be more consistent with other projects would be a a subtle, but good shift towards a generally better attitude of the expectations of minor releases. When PEP 6 was originally written, it said feature release, and bug fix release. This was then changed at some point (too lazy to look up subversion log now) to say major release and bugfix release, indicating that the major releases (in the sense of the common expectation) *are* the 2.x releases. At that time, it wasn't clear whether there ever would be a 3.0 release. This is where my understanding of policy comes from: bug fix releases are for bug fixes *only*, major releases can add new features, and correct problems that may break existing applications (using parallel APIs, warnings, etc, as appropriate). 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] Proposal to revert r54204 (splitext change)
Georg Brandl schrieb: As a sidenote, this item should be included in the 2.6 What's new's porting section. Perhaps it would be a good policy to automatically list potentially breaking fixes there instead of rolling off that task to Andrew. I would do that, except that Andrew explicitly reserved the right to change whatsnew.tex. I believe he does go over Misc/NEWS in doing so. 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] Proposal to revert r54204 (splitext change)
Stephen Hansen schrieb: And it'd be so easy to do it in a way which wouldn't be silent... just throw out a warning, and defer the actual change until the next release. Expecting people to keep on top of Misc/NEWS and re-read the documentation for every function in their code is a tad unreasonable. I don't personally find it unreasonable for people to ask for a bit more of an extended migration path when changes that are being implemented will cause *silent* changes in behavior. Which is why there is the Porting section in the What's New document, which is typically not longer than a page and should list these changes. Georg ___ 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] Proposal to revert r54204 (splitext change)
Stephen Hansen schrieb: And it'd be so easy to do it in a way which wouldn't be silent... just throw out a warning, and defer the actual change until the next release. I disagree that it easy to do that. Implementation-wise, it probably is. However, I feel that warnings have a *very* high cost, and cause more harm than good. They primarily don't appear at the machine of the author of the code. Instead, they appear at the end-user's machine, causing them problems in that they see messages from a software they didn't know they are even running. They all have to chase down the source of the program, only to eventually have the author of the software to tell them that it is safe to ignore this warning (which I believe it is). I specifically got complaints that Python fills Apache log files with garbage warnings. It won't help to issue the warning only once (although that will help in other cases): you then get the warning once per HTTP request (assuming CGI), which still can be a lot of warnings. That said, if it makes people more comfortable with having a warning added, I won't object. It's just that I don't want to be the one to take the blame for issuing the warning, because deep in my heart I feel that warnings are a bad thing, unless they are right most of the time (which they won't be in this case). (And, if I thought it'd have any chance of going in, I'd submit a patch to add a warning and adjust docs/tests/etc... but this issue seems ever so divided...) You need to find a committer to commit such a change, but otherwise, I think it's a good idea. Contributing is always a good idea. 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] Proposal to revert r54204 (splitext change)
On 08:43 pm, [EMAIL PROTECTED] wrote: On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 05:51 pm, [EMAIL PROTECTED] wrote: At 07:45 AM 3/15/2007 +0100, Martin v. L�wis wrote: I apparently took the same position that you now take back then, whereas I'm now leaning towards (or going beyond) the position Tim had back then, who wrote BTW, if it *weren't* for the code breakage, I'd be in favor of doing this. If it weren't for the code breakage, I'd be in favor too. That's not the point. The point is that how can Python be stable as a language if precedents can be reversed without a migration plan, just because somebody changes their mind? In another five years, will you change your mind again, and decide to put this back the way it was? Hear, hear. Python is _not_ stable as a language. I have Java programs that I wrote almost ten years ago which still run perfectly on the latest runtime. There is python software I wrote two years ago which doesn't work right on 2.5, and some of the Python stuff contemporary with that Java code won't even import. I think the problem has less to do with bug fixing than with lack of any clear specifications or documentation about what developers can depend on.You could probably make a case that any change that doesn't fix a crash bug is likely to cause some particular program to behave differently. Absolutely. One of the reasons I'm working on documenting this process is that, of course, *everything* can't be made compatible. The mere act of adding a function or module adds a detectable change in behavior that some program *might* insanely depend on. A clear understanding of what is meant by backwards compatibility is equally important to developers trying to future-proof their code as it is to those trying to make sure they don't break code which has been future-proofed. This is a form of social contract, and both sides need to know about it. Take bug 1504333 which lead to a change in sgmllib behavior for angle brackets in quoted attribute values. Did the sgmllib documentation explain that the fixed behavior was incorrect? Might a programmer working with sgmllib have written code that depended on this bug? Do you object to this bug fix? I don't know enough about the specification to say for sure, but I suspect that it is a legitimate bug fix, because sgmllib is implementing an externally-determined spec. In cases where the spec is flagrantly violated, it seems like it should be fixed to adhere to it. For many of these bugs, some people will have written code against the documentation and some people against the implementation or behavior. (In this case, the documentation is vague or conflicting.) I don't think I know how to balance the important of these two classes of users. Some code is going to break the first time they run into the under-specific edge case, some code is going to break when the specification and implementation are clarified. You have to weigh which you think is more likely and which will benefit users the most. If the documentation is vague and conflicting, then it seems likely that a parsing option could be added. I am not advocating perfect, 100% backwards compatibility, merely some standards for what happens when a (potentially) incompatible change is made. For example, you could add a flag to the parser which tweaks the treatment of quoted angle brackets, and warn if the argument is not passed that the default will change in the future (or, better yet, that the argument will be required in the future). Or, you could provide a separate name for invoking the different behavior. I think everyone wants to do the right thing by Python's users, but it's not clear what that right thing is. I really think that starting with the golden rule would be a good idea. Would Python core developers mind if something analogous in the C runtime changed? How would they cope with it? What kind of feedback would you expect the C compiler or runtime to provide in such a case? Python should do unto others, etc. Could you point out a few such programs that people on python-dev can look at? I think it would be useful to gather some data about the kind of migration pains real users are having. I believe Martin and others are trying to do the right thing. Real data is more likely to convince them than passionate arguments on python-dev. (I assume you're responding to my other comment about my programs not running, even though that's not what you quoted.) I don't think these programs would contribute much to the discussion. I've probably got them archived somewhere, but they were broken circa 2.3 and I don't think I've run them since. I doubt they would make any sense to anyone here, and we would all get into a heated debate as to whether my usage of Python was valid or not (hint: it was *REALLY* gross). In fact, let's back up a step. These programs were never released as
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
On 09:17 pm, [EMAIL PROTECTED] wrote: But the key point I want to get across is people should not being getting mad at Martin. The people who are getting all bent out of shape over this should be upset at python-dev as a whole for not having a clear policy on this sort of thing. Martin just happened to be the guy who made a change that sparked this and he is explaining his thinking behind it (which also happens to mirror my thinking on this whole situation). It could have easily been someone else. On part of this point, I have to agree. Nullum crimen, nulla poena sine praevia lege poenali. However, the decision was a bad one regardless of the existing policy, and sets a bad precedent while we are discussing this policy. I could be wrong, but I think it would be reasonable to assume that if Martin strongly supports such a change, Martin would oppose a policy which would strictly forbid such changes, and it is just such a policy that Python needs. Bottom line, let's work together as a group to come up with a policy in a civil, positive manner (in a new thread!) and let the result of that decision guide what is done with this fix. Yelling at poor Martin about one patch when we could be spending this effort on trying to discuss what kind of policy we want is not getting us anywhere. I *am* working on that on the side and I hope to have something coherent and whole to present here, in that different thread, very soon. The point, for me, of participating in *this* thread is (A) to continue to keep the issue high-visibility, because in my opinion, compatibility policy is _THE_ issue that python-dev needs to deal with now, (B) to deal with the aforementioned strongly implied opposition to such a policy, and (C) last but not least, to actually get the patch reverted, since, while it is not the larger problem, it is, itself, a problem that needs to be fixed. ___ 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] Proposal to revert r54204 (splitext change)
On 3/15/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Mike Krell schrieb:
Sure:
for f in files:
try:
(root, ext) = os.path.splitext(f)
os.rename(f, '%s.%s%s' % (root, index, ext))
except OSError:
die('renaming %s failed' % f)
Thanks! Looking more closely, it's not entirely clear where index
comes from - what if you already have a.1.txt. Will you set it
to 2? Will that then produce a.1.2.txt?
A bit more background: This runs periodically in a setting where the
files in the file list are regenerated in between invocations of this
code. Each time a renaming occurs, the index is incremented (it is
preserved in a file in between invocations). Thus, various
incarnations of a.txt would be archived as a.1.txt, a.2.txt,
etc. Similarly, copies of .emacs would be made as .1.emacs,
.2.emacs, etc. If b.1.txt appeared in the list of files to be
archived, it would be archived as b.1.1.txt, b.1.2.txt, etc.
Under the new patch, [.emacs] would be renamed to .emacs.1,
gratuitously breaking the extension preservation.
I can see that it breaks the behavior you intended it to have. However,
I disagree that it broke extension preservation. Rather, it *provides*
extension preservation, something that the old code did not do.
Here is a point of confusion. Bear in mind I'm running this under
windows, so explorer happily reports that .emacs has a type of
emacs. (In windows, file types are registered in the system based
on the extension -- all the characters following the last dot. An
unregistered extension is listed as its own type. Thus files ending
in .txt are listed as type Text Document, but files ending in
.emacs are listed as type emacs because it's an unregistered
extension.)
I often sort files in the explorer based on type, and I want a file
and all its backups to appear next to each other in such a sorted
list. That's exactly why I rename the files the way I do.
Thus, .1.emacs is what I want, and .emacs.1 is a markedly inferior
and unacceptable alternative. That's what I'm referring to by
extension preservation.
I also like to point out that the primary objective of the code
(archive arbitrary files) is still preserved - it still does that,
but in different manner. (disclaimer: I don't fully understand the
index part)
See above.
BTW, I want to echo Brett Cannon's comments about the tone. I've been
a bit testy about this breakage, however, upon reflection, it's clear
that it's not Martin's fault, but rather a shortcoming of the process.
Sorry, Martin. If you or anyone else was offended, please accept my
apologies.
Mike
___
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] Proposal to revert r54204 (splitext change)
On 3/15/07, Mike Krell [EMAIL PROTECTED] wrote: Here is a point of confusion. Bear in mind I'm running this under windows, so explorer happily reports that .emacs has a type of emacs. (In windows, file types are registered in the system based on the extension -- all the characters following the last dot. An unregistered extension is listed as its own type. Thus files ending in .txt are listed as type Text Document, but files ending in .emacs are listed as type emacs because it's an unregistered extension.) Unix-derived files prepended with a dot (like .emacs) are not meant to be interpreted as a file type. It may be useful on occasion when using windows, but it certainly is not the intent of a dotfile. The following files reside in my /tmp: .X0-lock .X100-lock .X101-lock .X102-lock .X103-lock .X104-lock .X105-lock .X106-lock .X11-unix .X99-lock ...which are certainly not all unnamed files of different type. I often sort files in the explorer based on type, and I want a file and all its backups to appear next to each other in such a sorted list. That's exactly why I rename the files the way I do. Thus, .1.emacs is what I want, and .emacs.1 is a markedly inferior and unacceptable alternative. That's what I'm referring to by extension preservation. Unacceptable? You code fails in (ISTM) the more common case of an extensionless file. -Mike ___ 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] Proposal to revert r54204 (splitext change)
On 3/15/07, Mike Klaas [EMAIL PROTECTED] wrote: Unacceptable? You code fails in (ISTM) the more common case of an extensionless file. I'm well aware of that limitation. However, what seems to you as a more common case is, in the context of this particular application, a case that never occurs. I wrote the code with my particular use cases in mind. Mike ___ 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] Proposal to revert r54204 (splitext change)
Mike Krell schrieb: Here is a point of confusion. Bear in mind I'm running this under windows, so explorer happily reports that .emacs has a type of emacs. (In windows, file types are registered in the system based on the extension -- all the characters following the last dot. Is it really that Emacs registered .emacs as an extension on Windows? (I see you answer that below) I would be surprised - I'd rather expect that the Emacs authors *don't* consider .emacs to be a file with an empty filename and a .emacs extension. They also (alternatively) support a directory called .emacs.d for startup files, and I would be equally surprised if they registered .d as extension (about the only extension Emacs might register is .el/.elc). The reason the file is called .emacs on Windows is *not* because it should have that extension, but because it is called .emacs on Unix, and it is called that way because the Unix shell and ls suppress dotfiles unless explicitly asked to display them. I often sort files in the explorer based on type, and I want a file and all its backups to appear next to each other in such a sorted list. That's exactly why I rename the files the way I do. Thus, .1.emacs is what I want, and .emacs.1 is a markedly inferior and unacceptable alternative. That's what I'm referring to by extension preservation. Ok, I see why that would break. What do you do with files that really have no extension whatsoever (i.e. no dot at all)? 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] Proposal to revert r54204 (splitext change)
On 3/15/07, Martin v. Löwis [EMAIL PROTECTED] wrote: *don't* consider .emacs to be a file with an empty filename and a .emacs extension. They also (alternatively) support a directory called .emacs.d for startup files, and I would be equally surprised if they registered .d as extension (about the only extension Emacs might register is .el/.elc). Agreed on both counts. I'm sure neither of these are registered extensions, but for what I care about the operative question is what windows explorer does with (what it considers to be) unregistered extensions. The reason the file is called .emacs on Windows is *not* because it should have that extension, but because it is called .emacs on Unix, and it is called that way because the Unix shell and ls suppress dotfiles unless explicitly asked to display them. Yes. Ok, I see why that would break. What do you do with files that really have no extension whatsoever (i.e. no dot at all)? That use case doesn't come up for this application -- see my response to Mike Klass. I actually muddied the waters here by using .emacs as an example. In practice, this app would never copy a .emacs file since its used to copy files used by itself. Mike ___ 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] Proposal to revert r54204 (splitext change)
On Friday 16 March 2007 07:57, [EMAIL PROTECTED] wrote: Common parlance for the parts of a version number is: major.minor.micro See: http://twistedmatrix.com/documents/current/api/twisted.python.ver sions.Version.html#__init__ Changing this terminology about Python releases to be more consistent with other projects would be a a subtle, but good shift towards a generally better attitude of the expectations of minor releases. I disagree entirely. Python has major releases, and bugfix releases. At the moment, the major releases are of the form 2.x, and bugfix 2.x.y. Trying to say that 2.4-2.5 is a minor release is just nonsensical. That suggests that very little new language development would go on, at all. Now, you might be arguing that in fact very little should go on (I know some people have argued this, I can't remember if you were one of these). My standard response to this is that people who really feel like this are welcome to pick a release, say, 2.3, and take on the process of backporting the relevant bugfixes back to that release, and cutting new releases, c. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] Proposal to revert r54204 (splitext change)
Mike Krell wrote: I want .emacs to be renamed to .1.emacs, thus preserving the extensions. Under the new patch, the second file would be renamed to .emacs.1, gratuitously breaking the extension preservation. This argument presupposes that .emacs on its own should be considered an extension, which is the very thing under dispute. If it's not considered an extension, it gets renamed to .emacs.1, just the same as any other file with no extension, e.g. foo to foo.1. So it's equally consistent whichever way you think of it. -- Greg ___ 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] Proposal to revert r54204 (splitext change)
Mike Krell wrote: copies of .emacs would be made as .1.emacs, .2.emacs, etc. But that's not going to work for other extensionless files that don't begin with a dot. The fact that it happens to work for .emacs files and the like is just a fluke due to Windows' ignorance of Unix file naming conventions. -- Greg ___ 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] Proposal to revert r54204 (splitext change)
Anthony Baxter wrote: Python has major releases, and bugfix releases. At the moment, the major releases are of the form 2.x, and bugfix 2.x.y. Yes, and from history so far there's no particular semantics attached to first-digit transitions. 1.x - 2.x was nothing to write home about, and 2.x - 3.x is going to be something like a mega release. -- Greg ___ 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] Proposal to revert r54204 (splitext change)
On 3/15/07, Martin v. Löwis [EMAIL PROTECTED] wrote: If we both agree that the old behavior was erroneous, then I cannot understand why you want to see the patch reverted. I think at least part of the disagreement is over the classification of the earlier behavior as erroneous. Both unexpected and undesirable have certainly been common classifications, but as not everyone agrees, and a very visible example in Windows Explorer disagree, it's hard to settle on this behavior being simply incorrect. Thus it's a value judgement. Unlike other value judgements reflected in Misc/NEWS, there are no similar APIs with which we can compare behavior and match to increase consistency. Michael -- Michael Urman http://www.tortall.net/mu/blog ___ 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] Proposal to revert r54204 (splitext change)
At 01:30 PM 3/16/2007 +1300, Greg Ewing wrote: Mike Krell wrote: I want .emacs to be renamed to .1.emacs, thus preserving the extensions. Under the new patch, the second file would be renamed to .emacs.1, gratuitously breaking the extension preservation. This argument presupposes that .emacs on its own should be considered an extension, which is the very thing under dispute. It's not under dispute for *him*, nor is it under dispute that Windows Explorer treats it that way. What's *actually* under dispute here is whether it's acceptable to classify this perfectly useful-as-is behavior, that was documented and tested in released versions of Python for several years (with patches to change its behavior explicitly rejected in the past), as a bug. Unfortunately, people who are on the other side of the issue seem unable to conceive of the possibility that there are people who legitimately *don't* think this is a bug. However, just because someone doesn't like it, doesn't make it a bug. Design flaw? Wart? Oversight? Perhaps. But bug? When it's explicitly documented and tested, and there exist legitimate uses of the existing behavior, even among Python-dev'ers? Heck no. Unfortunately, because some people have it in their heads that '.emacs' is not a file extension (to *them*), they aren't able to handle the idea that on Windows, it bloody well *is* a file extension, and some people would like to treat it as such *even on non-Windows platforms*. They don't seem to understand that it doesn't matter how many posts they write explaining to us poor deluded souls that their interpretation of extension is the only correct interpretation, it isn't going to change the fact that there are *many* valid interpretations. Reasonable people can therefore dispute what splitext should consider to be an extension - and it's been further pointed out that at one time, splitext() could and did consider '.tar.gz' to be the extension! So, no matter how many times people call this a bug, it is *not* a bug. It is merely a feature that more people (in a straw poll of Python-dev) dislike than like. However, a straw poll of Python users at large might reveal that Python's explicit self pattern is unpopular. Should we consider that a bug, then, and fix it too, if someone offered a patch for it, because they wrote a program using Java-style implicit self, and it didn't work? Yes, let's change Python so that methods and attributes don't need a self parameter or a self., and silently change the meaning of existing programs, because clearly anybody who *likes* explicit self is wrong and wrote a bad program. So let's just fix their program by silently changing its meaning underneath them, because surely they meant 'self' to be some other function argument, and now anybody who writes new programs in this style will have them work! (And if you think that this isn't a fair comparison, it's because you're not looking at it from the POV of those who like the current splitext() behavior.) As Glyph says, this change is *punishing the conscientious* (i.e., everyone who actually read the docstrings and/or tested their code in the last decade and a half) to reward people who were NOT conscientious. That seems backwards to me. ___ 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] Proposal to revert r54204 (splitext change)
At 10:39 PM 3/15/2007 +0100, Martin v. Löwis wrote: That said, if it makes people more comfortable with having a warning added, I won't object. It's just that I don't want to be the one to take the blame for issuing the warning, because deep in my heart I feel that warnings are a bad thing, unless they are right most of the time (which they won't be in this case). Some other options: 1. Deprecate splitext() and remove it in 3.0 2. Add an optional flag argument to enable the new behavior 3. Create a new function with the new behavior (as you proposed the last time there was a patch submitted for this) ___ 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] Proposal to revert r54204 (splitext change)
On 3/15/07, Steve Holden [EMAIL PROTECTED] wrote: The fact remains that those who have used the existing functionality as it is implemented and documented will, of this change isn't reverted, have to make a gratuitous change to their currently working programs. The worst part is, if they are relying on that specific behavior and have to rely on the new specific behavior, and want to support old and new versions of Python, they are potentially left with some very unattractive options -- check the Python version to figure out how splitext works, or just roll their own and stop calling splitext entirely, because its behavior is not consistent across versions. Because some immoderate language has been used in this thread I would like to underline that these remarks are not directed personally at Martin, for whom I have the utmost respect as a developer, but at the lack of process that allows circumstances like this to arise. I second this sentiment. Regards, Pat ___ 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] Proposal to revert r54204 (splitext change)
For anyone who is interested, I've submitted a patch (source + docs + tests) to SF as 1681842, which re-establishes the previous behavior, but adds a keyword argument to obtain the new behavior and a warning promising the new behavior will become default in the future. ...which would be my second contribution ever. And the first one to be more then a line and a half :P -- Stephen Hansen Development Advanced Prepress Technology [EMAIL PROTECTED] (818) 748-9282 ___ 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] Proposal to revert r54204 (splitext change)
Mike Krell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I actually muddied the waters here by using .emacs as an example. In practice, this app would never copy a .emacs file since its used to copy files used by itself. Do you actually save any files 'named' '.xxx'? ___ 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] As to the usefulness of current behavior, the only supposed use-case code posted, that I have noticed, was that it made it easy to turn '.emacs' into '1.emacs', but then MK said the app does not really do that. As for comparison with changing 'self'... | (And if you think that this isn't a fair comparison, I think it is a ludicrous comparison, not even in the same ballpark, that tends to discredit the valid points you have made. | it's because you're | not looking at it from the POV of those who like the current splitext() | behavior.) I get annoyed when people tell me why I think the way I do, especially when they are so badly mistaken. 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby schrieb: This backwards-incompatible change is therefore contrary to policy and should be reverted, pending a proper transition plan for the change (such as introduction of an alternative API and deprecation of the existing one.) I'm clearly opposed to this proposal, or else I wouldn't have committed the change in the first place. 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] Proposal to revert r54204 (splitext change)
At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote: Phillip J. Eby schrieb: This backwards-incompatible change is therefore contrary to policy and should be reverted, pending a proper transition plan for the change (such as introduction of an alternative API and deprecation of the existing one.) I'm clearly opposed to this proposal, or else I wouldn't have committed the change in the first place. That much is obvious. But I haven't seen any explanation as to why explicitly-documented and explicitly-tested behavior should be treated as a bug in policy terms, just because people don't like the documented and tested behavior. So far, the only policy justification I've seen you give was along the lines of, I volunteered to do it, so I get to decide. If this statement were actually a valid policy, then I suppose I could simply volunteer to decide to revert the change. But if it's *not* a valid policy, then there is no policy justification for the change, and therefore it should be reverted. Thus, either way, there needs to be some *other* justification for the original change. ___ 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby wrote: At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote: Phillip J. Eby schrieb: This backwards-incompatible change is therefore contrary to policy and should be reverted, pending a proper transition plan for the change (such as introduction of an alternative API and deprecation of the existing one.) I'm clearly opposed to this proposal, or else I wouldn't have committed the change in the first place. That much is obvious. But I haven't seen any explanation as to why explicitly-documented and explicitly-tested behavior should be treated as a bug in policy terms, just because people don't like the documented and tested behavior. Because it's clearly a bug and has even been shown to fix bugs in current code ? Honestly it is this sort of pointless prevarication that gives python-dev a bad name. Michael Foord ___ 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] Proposal to revert r54204 (splitext change)
On 3/14/07, Michael Foord [EMAIL PROTECTED] wrote: Phillip J. Eby wrote: At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote: Phillip J. Eby schrieb: This backwards-incompatible change is therefore contrary to policy and should be reverted, pending a proper transition plan for the change (such as introduction of an alternative API and deprecation of the existing one.) I'm clearly opposed to this proposal, or else I wouldn't have committed the change in the first place. That much is obvious. But I haven't seen any explanation as to why explicitly-documented and explicitly-tested behavior should be treated as a bug in policy terms, just because people don't like the documented and tested behavior. Because it's clearly a bug and has even been shown to fix bugs in current code ? Honestly it is this sort of pointless prevarication that gives python-dev a bad name. However, changing documented, tested behaviour without warning gives Python an even worse name. I agree with PJE that the change is the wrong thing to do, simply because it sets (yet another) precedent. If providing an alternate API with clearer semantics is too 'heavy-weight' a solution and warning is for some reason unacceptable (I don't see why; all the arguments against warning there go for *any* warning in Python) -- then the problem isn't bad enough to fix it by breaking other code. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby wrote: In addition to being made in the face of controversy and opposition, this change is an alteration to *documented and tested* behavior and thus cannot reasonably be considered a mere bug fix. FWIW, I support Phillip on this. There can be no question that the old behaviour was expected. IMO this is just gratuitous breakage. The only fix that shold be made is to the splitext documentation to match the docstring. A change to the documented behaviour should require a __future__ import for at least one version. That's even assuming that the change is desireable (I don't believe so). We have multiple anecdotes of actual, existing code that *will* break with this change. So far I haven't seen any actual code posted that is currently broken by the existing behaviour. Tim Delaney ___ 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] Proposal to revert r54204 (splitext change)
At 08:30 AM 3/15/2007 +1100, Delaney, Timothy (Tim) wrote: Phillip J. Eby wrote: In addition to being made in the face of controversy and opposition, this change is an alteration to *documented and tested* behavior and thus cannot reasonably be considered a mere bug fix. FWIW, I support Phillip on this. There can be no question that the old behaviour was expected. IMO this is just gratuitous breakage. The only fix that shold be made is to the splitext documentation to match the docstring. A change to the documented behaviour should require a __future__ import for at least one version. That's even assuming that the change is desireable (I don't believe so). We have multiple anecdotes of actual, existing code that *will* break with this change. So far I haven't seen any actual code posted that is currently broken by the existing behaviour. FWIW, I think that, were we writing splitext() *now*, we should go with the proposed behavior. It's reasonable and justifiable even on Windows (even though Windows Explorer agrees with the current splitext() behavior.) But, that doesn't actually have any bearing on the current discussion, since splitext()'s behavior is existing and documented. Certainly, there *is* code that's broken by the existing behavior -- otherwise the patch would never have been submitted in the first place. However, that doesn't automatically make it a Python bug, especially if the existing behavior is documented and covered by regression tests. I just want to clarify this point, because I don't wish to enter another round of discussion about the merits of one behavior or the other: the merits one way or the other are pretty much irrelevant to the policy issue at hand. ___ 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] Proposal to revert r54204 (splitext change)
Delaney, Timothy (Tim) wrote: Phillip J. Eby wrote: In addition to being made in the face of controversy and opposition, this change is an alteration to *documented and tested* behavior and thus cannot reasonably be considered a mere bug fix. FWIW, I support Phillip on this. There can be no question that the old behaviour was expected. Expected ? It's perverse. :-) IMO this is just gratuitous breakage. The only fix that shold be made is to the splitext documentation to match the docstring. Agreed. A change to the documented behaviour should require a __future__ import for at least one version. That's even assuming that the change is desireable (I don't believe so). We have multiple anecdotes of actual, existing code that *will* break with this change. So far I haven't seen any actual code posted that is currently broken by the existing behaviour. There was code posted that used the (almost entirely sane) pattern : new_filename = os.path.splitext(old_filename)[1] + '.bak' That was broken but is now fixed. It follows the entirely natural assumption that filename without an extension would not have the filename put in the extension half of the tuple. The documentation (not the docstring) actually says : splitext( path) Split the pathname path into a pair (root, ext) such that root + ext == path, and ext is empty or begins with a period and contains at most one period. Even the docstring only states that either part may be empty, hardly documenting what is clearly a misfeature. Michael Foord Tim Delaney ___ 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.uk ___ 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] Proposal to revert r54204 (splitext change)
Phillip J. Eby wrote: At 08:30 AM 3/15/2007 +1100, Delaney, Timothy (Tim) wrote: Phillip J. Eby wrote: In addition to being made in the face of controversy and opposition, this change is an alteration to *documented and tested* behavior and thus cannot reasonably be considered a mere bug fix. FWIW, I support Phillip on this. There can be no question that the old behaviour was expected. IMO this is just gratuitous breakage. The only fix that shold be made is to the splitext documentation to match the docstring. A change to the documented behaviour should require a __future__ import for at least one version. That's even assuming that the change is desireable (I don't believe so). We have multiple anecdotes of actual, existing code that *will* break with this change. So far I haven't seen any actual code posted that is currently broken by the existing behaviour. FWIW, I think that, were we writing splitext() *now*, we should go with the proposed behavior. It's reasonable and justifiable even on Windows (even though Windows Explorer agrees with the current splitext() behavior.) But, that doesn't actually have any bearing on the current discussion, since splitext()'s behavior is existing and documented. Certainly, there *is* code that's broken by the existing behavior -- otherwise the patch would never have been submitted in the first place. However, that doesn't automatically make it a Python bug, especially if the existing behavior is documented and covered by regression tests. I just want to clarify this point, because I don't wish to enter another round of discussion about the merits of one behavior or the other: the merits one way or the other are pretty much irrelevant to the policy issue at hand. It looks to me like a clear bugfix (the fact that there were unit tests for the insane behaviour doesn't make it any less a bug). The current docstring that states that the first element may be empty hardly counts as it being a 'documented feature'. At the least it is a grey area and not a policy reversal. The policy is that bugfixes can go in with warnings. So, as a debatable issue whether it is a bug (I think it is fairly clear), then it doesn't change or contravene policy. Michael Foord ___ 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.uk ___ 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] Proposal to revert r54204 (splitext change)
Michael Foord wrote: There was code posted that used the (almost entirely sane) pattern : new_filename = os.path.splitext(old_filename)[1] + '.bak' That was broken but is now fixed. It follows the entirely natural assumption that filename without an extension would not have the filename put in the extension half of the tuple. Well, I'd argue the sanity of it, but you're right - it was posted. The documentation (not the docstring) actually says : splitext( path) Split the pathname path into a pair (root, ext) such that root + ext == path, and ext is empty or begins with a period and contains at most one period. Even the docstring only states that either part may be empty, hardly documenting what is clearly a misfeature. splitext(p) Split the extension from a pathname. Extension is everything from the last dot to the end. ^ Return (root, ext), either part may be empty. That's pretty explicit. Tim Delaney ___ 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
