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 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
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 proble
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)
>
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",
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
yo
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
si
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 docum
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
> 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 someth
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 fo
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 a
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 the
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
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
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
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 parti
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
U
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 th
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
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 g
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.
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.
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 le
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 h
"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 w
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 th
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
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/mail
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
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.
>
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
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 existi
"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
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
>> com
-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
>>
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 patche
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
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
___
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 behavio
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 sev
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
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 "e
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
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
>
>
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
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
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 compatibi
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
> p
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 expli
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
"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 fo
"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'?
___
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
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 a
Michael Urman wrote:
> 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 beh
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, un
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 pres
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 unex
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
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 namin
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 e
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 m
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 (
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
[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 opp
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 oc
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
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('renam
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 hap
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 goin
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 cos
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
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 ex
[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:
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 Pyt
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
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
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
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 wa
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),
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('ren
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
"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 fam
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
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
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
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'
> 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",
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 address
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 i
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,
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 w
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
[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 *
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 c
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
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
pat
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
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" f
1 - 100 of 121 matches
Mail list logo
