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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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.
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:
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
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
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
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,
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
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
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
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?
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
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
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
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
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
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
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
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
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
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,
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
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
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).
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
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,
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:
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),
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
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
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
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
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
[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:
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
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
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
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
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
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)
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
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
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
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
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
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,
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
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
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
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
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,
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
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
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'?
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
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
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
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
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
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
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
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.
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
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
1 - 100 of 117 matches
Mail list logo
