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
Delaney, Timothy (Tim) wrote:
[snip..]
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.
Phillip J. Eby schrieb:
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.
It's not just that people disliked
On 3/14/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
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 think the original
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
Delaney, Timothy (Tim) schrieb:
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
Martin v. Löwis wrote:
It's not just that people disliked the behavior. The majority of
those
that commented agreed that the current behavior is incorrect. Some
also
observed that the online documentation was underspecified, and indeed
allowed for that change. So this is a bug fix, even
At 10:54 PM 3/14/2007 +0100, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
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
Hi Martin,
On Wed, Mar 14, 2007 at 10:54:41PM +0100, Martin v. L?wis wrote:
So this is a bug fix, even though the old test
case explicitly tested for the presence of the bug
FWIW, when developing PyPy we found quite a number of tests in CPython
that were checking not just obscure
On 3/14/07, Phillip J. Eby [EMAIL PROTECTED] 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
On 14 Mar, 05:08 pm, [EMAIL PROTECTED] wrote:
In addition to the prior behavior being explicitly documented in the
function docstrings, r54204 shows that it was also *tested* as behaving
that way by test_macpath, test_ntpath, and test_posixpath. When
combined
with the explicit docstrings,
On Thursday 15 March 2007 08:54, Martin v. Löwis wrote:
The bug fix may also break existing applications. Hence it cannot
go into 2.5.1 but has to wait for 2.6.
Steering clear of the rest of the discussion, I'd just like to give
a hearty +1 for this not going into 2.5.x in any way shape or
Anthony On Thursday 15 March 2007 08:54, Martin v. Löwis wrote:
The bug fix may also break existing applications. Hence it cannot go
into 2.5.1 but has to wait for 2.6.
Anthony Steering clear of the rest of the discussion, I'd just like to
Anthony give a hearty +1 for this
On 3/14/07, Anthony Baxter [EMAIL PROTECTED] wrote:
Steering clear of the rest of the discussion, I'd just like to give
a hearty +1 for this not going into 2.5.x in any way shape or
form.
Agreed. I'd further vote for keeping this change out until 3.x because
it is a behavior change in a corner
Michael Urman wrote:
Who would rather see os.path.dropext(path)?
I'd like to see such a function, and also
maybe replaceext(path, new_ext). I often
end up coding things like these myself,
since indexing the result of splitext all
the time is rather ugly.
To round off the set, I suggest
Good, we have gotten around to discussing a little annoyance I've
noticed. I think this should behave similar to the way a Unix admin who
is familiar with basename(1) would behave:
$ basename -s .py
/tmp/foo.py
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
[EMAIL PROTECTED] 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 hope that this is true, but *is* this
101 - 118 of 118 matches
Mail list logo
