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
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)
|
|
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
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:
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:
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 that.
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
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 points:
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
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
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
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
[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
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
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),
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 in good
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
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
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
[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
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,
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-running
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
56 matches
Mail list logo
