"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
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > Can you suggest any use-cases for thread termination which will *not*
> > result in a completely broken and unpredictable heap after the thread
> > has died?
>
> Suppose you have a GUI and you want to launch a
> long-run
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 (
[EMAIL PROTECTED] wrote:
> Can you suggest any use-cases for thread termination which will *not*
> result in a completely broken and unpredictable heap after the thread
> has died?
Suppose you have a GUI and you want to launch a
long-running computation without blocking the
user interface. You
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
Facundo Batista wrote:
> are there processors that support "reentrant" interrupts?
The PDP11 had seven priority levels for interrupts.
When an interrupt was handled, interrupts with
priorities less than or equal to the current level
were blocked, but the handler could be interrupted
by a higher p
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
I'll review it tomorrow.
Georg
Guido van Rossum schrieb:
> I need to shed load; I've asked Georg to review this. If he's fine
> with it, Facundo can check it in.
>
> On 3/15/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>> Facundo Batista wrote:
>>
>> > I studied Skip patch, and I think he is i
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
I need to shed load; I've asked Georg to review this. If he's fine
with it, Facundo can check it in.
On 3/15/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> Facundo Batista wrote:
>
> > I studied Skip patch, and I think he is in good direction: add a
> > NetworkConnection object to socket.py, and
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
Facundo Batista wrote:
> I studied Skip patch, and I think he is in good direction: add a
> NetworkConnection object to socket.py, and then use it from the other
> modules.
As of discussion in the patch tracker, this class is now a function in
socket.py.
This function connect() does the connect
[EMAIL PROTECTED] schrieb:
> Just in case it's not clear from the other things I've said: this is a
> terrible, terrible idea, and I am shocked that it is even being
> *considered* for inclusion in Python. As a foolish youth, I wasted many
> months trying to get a program that used Java's (then
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,
On 04:24 pm, [EMAIL PROTECTED] wrote:
Jean-Paul Calderone schrieb:
I inferred from Martin's proposal that he
expected the thread to be able to catch the exception. Perhaps he
can
elaborate on what cleanup actions the dying thread will be allowed to
perform.
Perhaps he can. Hopefully, he ca
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
Martin v. Löwis wrote:
> asynchronous exceptions in a sensible way. I have to research somewhat
> more, but I think the standard solution to the problem in operating
> system (i.e. disabling interrupts at certain points, explicitly
> due to code or implicitly as a result of entering the interrupt
Jean-Paul Calderone schrieb:
>> I inferred from Martin's proposal that he
>> expected the thread to be able to catch the exception. Perhaps he can
>> elaborate on what cleanup actions the dying thread will be allowed to
>> perform.
>
> Perhaps he can. Hopefully, he can specifically address these
On Thu, 15 Mar 2007 09:41:31 -0500, [EMAIL PROTECTED] wrote:
>
>>> I just proposed to implement thread cancellation for the SoC. Is
>>> there any prior work where one could start?
>
>Jean-Paul> The outcome of some prior work, at least:
>
>Jean-Paul>
> http://java.sun.com/j2se/1.
>> I just proposed to implement thread cancellation for the SoC. Is
>> there any prior work where one could start?
Jean-Paul> The outcome of some prior work, at least:
Jean-Paul>
http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
I responded to th
On Thu, 15 Mar 2007 14:34:15 +0100, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>I just proposed to implement thread cancellation for the SoC.
>Is there any prior work where one could start?
The outcome of some prior work, at least:
http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPri
I just proposed to implement thread cancellation for the SoC.
Is there any prior work where one could start?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
holger krekel wrote:
> Hello Python-dev!
Hello Holger!
> We'd be very happy about feedback and opinions/questions
> (preferably until Monday, 19th March)
>
>
> http://codespeak.net/pypy/extradoc/eu-report/D12.1_H-L-Backends_and_Feature_Prototypes-interim-2007-03-12.pdf
It seems quite int
Terry Reedy wrote:
> "holger krekel" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | We'd be very happy about feedback and opinions/questions
> | (preferably until Monday, 19th March)
> |
> |
> http://codespeak.net/pypy/extradoc/eu-report/D12.1_H-L-Backends_and_Feature_Prototype
58 matches
Mail list logo