Re: [Python-Dev] Proposal to revert r54204 (splitext change)
"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 comparison with changing 'self'... | (And if you think that this isn't a fair comparison, I think it is a ludicrous comparison, not even in the same ballpark, that tends to discredit the valid points you have made. | it's because you're | not looking at it from the POV of those who like the current splitext() | behavior.) I get annoyed when people tell me why I think the way I do, especially when they are so badly mistaken. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
"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'? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 contribution ever. And the first one to be more then a line and a half :P -- Stephen Hansen Development Advanced Prepress Technology [EMAIL PROTECTED] (818) 748-9282 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 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 how splitext works, or just roll their own and stop calling splitext entirely, because its behavior is not consistent across versions. > Because some immoderate language has been used in this thread I would > like to underline that these remarks are not directed personally at > Martin, for whom I have the utmost respect as a developer, but at the > lack of process that allows circumstances like this to arise. I second this sentiment. Regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 behavior as "erroneous". Both unexpected and > undesirable have certainly been common classifications, but as not > everyone agrees, and a very visible example in Windows Explorer > disagree, it's hard to settle on this behavior being simply incorrect. > Thus it's a value judgement. Unlike other value judgements reflected > in Misc/NEWS, there are no similar APIs with which we can compare > behavior and match to increase consistency. 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. I'm not really too concerned with whether the behavior is "erroneous" - that is indeed in the realm of value judgment. I'm concerned about the impression the user community will get as they see such changes made to the language with no more apparent justification than the whim of an individual developer. Because some immoderate language has been used in this thread I would like to underline that these remarks are not directed personally at Martin, for whom I have the utmost respect as a developer, but at the lack of process that allows circumstances like this to arise. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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, unless they are right most of the >time (which they won't be in this case). Some other options: 1. Deprecate splitext() and remove it in 3.0 2. Add an optional flag argument to enable the new behavior 3. Create a new function with the new behavior (as you proposed the last time there was a patch submitted for this) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 ".emacs" on its own >should be considered an extension, which is the >very thing under dispute. It's not under dispute for *him*, nor is it under dispute that Windows Explorer treats it that way. 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 rejected in the past), as a "bug". Unfortunately, people who are on the other side of the issue seem unable to conceive of the possibility that there are people who legitimately *don't* think this is a bug. However, just because someone doesn't like it, doesn't make it a bug. Design flaw? Wart? Oversight? Perhaps. But bug? When it's explicitly documented and tested, and there exist legitimate uses of the existing behavior, even among Python-dev'ers? Heck no. Unfortunately, because some people have it in their heads that "'.emacs' is not a file extension" (to *them*), they aren't able to handle the idea that on Windows, it bloody well *is* a file extension, and some people would like to treat it as such *even on non-Windows platforms*. They don't seem to understand that it doesn't matter how many posts they write "explaining" to us poor deluded souls that their interpretation of "extension" is the only correct interpretation, it isn't going to change the fact that there are *many* valid interpretations. Reasonable people can therefore dispute what "splitext" should consider to be an "extension" - and it's been further pointed out that at one time, splitext() could and did consider '.tar.gz' to be the "extension"! So, no matter how many times people call this a "bug", it is *not* a bug. It is merely a feature that "more" people (in a straw poll of Python-dev) dislike than like. However, a straw poll of Python users at large might reveal that Python's "explicit self" pattern is unpopular. Should we consider that a bug, then, and "fix" it too, if someone offered a patch for it, because they wrote a program using Java-style implicit self, and it didn't work? Yes, let's change Python so that methods and attributes don't need a self parameter or a "self.", and silently change the meaning of existing programs, because clearly anybody who *likes* explicit self is wrong and wrote a bad program. So let's just "fix" their program by silently changing its meaning underneath them, because surely they meant 'self' to be some other function argument, and now anybody who writes new programs in this style will have them work! (And if you think that this isn't a fair comparison, it's because you're not looking at it from the POV of those who like the current splitext() behavior.) As Glyph says, this change is *punishing the conscientious* (i.e., everyone who actually read the docstrings and/or tested their code in the last decade and a half) to reward people who were NOT conscientious. That seems backwards to me. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 and undesirable have certainly been common classifications, but as not everyone agrees, and a very visible example in Windows Explorer disagree, it's hard to settle on this behavior being simply incorrect. Thus it's a value judgement. Unlike other value judgements reflected in Misc/NEWS, there are no similar APIs with which we can compare behavior and match to increase consistency. Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 -> 3.x is going to be something like a "mega" release. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 conventions. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
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 computation without blocking the > user interface. You don't know how long it will > take, so you want the user to be able to cancel > it if he gets bored. If the code is in Python, you can use sys.settrace to handle this. If the code is in an extension module that a user has control over, having a cancel_thread() function that is made available to Python, and having your C code check the value of a single variable every few seconds could do the same thing (even checking the value in a tight loop shouldn't slow computations down significantly, branch prediction should be able to make it a more or less zero-cost operation). Yes, it can be tedious, but at least the programmer can actually control cleanup in a reasonable manner. The only case that I have been able to come up with that is not covered with these two is if you have no control over the C-level code, which would be the case in a precompiled 3rd party extension or system call. In the system call case, I'm not sure there is a sane way to abort it on all platforms, and I can just about guarantee that even if you *could* kill a thread, doing so in 3rd party code (depending on the code) could leave you in a questionable state (memory leaks, temporary files, broken data structures, etc.). It seems better to write to allow for cancellation, rather than adding a big red STOP button to threads. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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, which is the very thing under dispute. If it's not considered an extension, it gets renamed to ".emacs.1", just the same as any other file with no extension, e.g. "foo" to "foo.1". So it's equally consistent whichever way you think of it. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 > consistent with other projects would be a a subtle, but good > shift towards a generally better attitude of the expectations of > "minor" releases. I disagree entirely. Python has major releases, and bugfix releases. At the moment, the major releases are of the form 2.x, and bugfix 2.x.y. Trying to say that 2.4->2.5 is a "minor" release is just nonsensical. That suggests that very little new language development would go on, at all. Now, you might be arguing that in fact very little should go on (I know some people have argued this, I can't remember if you were one of these). My standard response to this is that people who really feel like this are welcome to pick a release, say, 2.3, and take on the process of backporting the relevant bugfixes back to that release, and cutting new releases, &c. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 the only extension Emacs > might register is .el/.elc). Agreed on both counts. I'm sure neither of these are registered extensions, but for what I care about the operative question is what windows explorer does with (what it considers to be) unregistered extensions. > The reason the file is called .emacs on Windows is *not* because > it should have that extension, but because it is called .emacs > on Unix, and it is called that way because the Unix shell and ls > suppress dotfiles unless explicitly asked to display them. Yes. > Ok, I see why that would break. What do you do with files that really > have no extension whatsoever (i.e. no dot at all)? That use case doesn't come up for this application -- see my response to Mike Klass. 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. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
[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 don't know how long it will take, so you want the user to be able to cancel it if he gets bored. There's no single place in the code where you could put in a check for cancellation. Sprinkling such checks all over the place would be tedious, or even impossible if large amounts of time are spent in calls to a third-party library that wasn't designed for such things. Interaction with the rest of the program is extremely limited -- some data is passed in, it churns away, and some data is returned. It doesn't matter what happens to its internal state if it gets interrupted, as it's all going to be thrown away. In that situation, it doesn't seem unreasonable to me to want to be able to just kill the thread. I don't see how it could do any more harm than using KeyboardInterrupt to kill a program, because that's all it is -- a subprogram running inside your main program. How would you handle this situation? > If you can think of such a case, are you sure it wouldn't be > better served by a set of threads communicating over queues and sending > 'Stop' objects to each other If the thread is guaranteed to return to reading from the queue within a bounded time, that's fine, and it's the solution I would recommend in that case. But not all cases are like that. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 that Emacs registered .emacs as an extension on Windows? (I see you answer that below) I would be surprised - I'd rather expect that the Emacs authors *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 the only extension Emacs might register is .el/.elc). The reason the file is called .emacs on Windows is *not* because it should have that extension, but because it is called .emacs on Unix, and it is called that way because the Unix shell and ls suppress dotfiles unless explicitly asked to display them. > I often sort files in the explorer based on type, and I want a file > and all its backups to appear next to each other in such a sorted > list. That's exactly why I rename the files the way I do. > Thus, ".1.emacs" is what I want, and ".emacs.1" is a markedly inferior > and unacceptable alternative. That's what I'm referring to by > extension preservation. Ok, I see why that would break. What do you do with files that really have no extension whatsoever (i.e. no dot at all)? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
[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 oppose a policy which > would strictly forbid such changes, and it is just such a policy that > Python needs. I still can't guess what policy you have in mind, so I can't object to it :-) I may accept a policy that rejects this change, but allows another change to fix the problem. I would oppose a policy that causes this bug to be unfixable forever. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
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 priority interrupt. Also, on any processor I know about, there's nothing to stop an interrupt handler re-enabling interrupts once it's ensured that the particular one it's handling isn't going to happen again. You can use this to implement an interrupt priority scheme in software if the hardware doesn't support it. So yes, re-entrant interrupts do make sense in some situations. The thing to model this on, I think, would be the BSD sigmask mechanism, which lets you selectively block certain signals to create a critical section of code. A context manager could be used to make its use easier and less error-prone (i.e. harder to block async exceptions and then forget to unblock them). > But, in that scenario, should be a way to say to the thread "Die, die > now, no matter what"? Unconditionally killing a whole process is no big problem because all the resources it's using get cleaned up by the OS, and the effect on other processes is minimal and well-defined (pipes and sockets get EOF, etc.). But killing a thread can leave the rest of the program in an awkward state. I'm inclined to think that there should be some way to do it, and any locks held by the killed thread should be broken. It's then up to the program to deal with the consequences. If it's not willing to do that, then it shouldn't use the instant-death mechanism. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 occurs. I wrote the code with my particular use cases in mind. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 the last dot. An > unregistered extension is listed as its own type. Thus files ending > in .txt are listed as type "Text Document", but files ending in > ".emacs" are listed as type "emacs" because it's an unregistered > extension.) Unix-derived files prepended with a dot (like .emacs) are not meant to be interpreted as a "file type". It may be useful on occasion when using windows, but it certainly is not the intent of a dotfile. The following files reside in my /tmp: .X0-lock .X100-lock .X101-lock .X102-lock .X103-lock .X104-lock .X105-lock .X106-lock .X11-unix .X99-lock ...which are certainly not all unnamed files of different type. > I often sort files in the explorer based on type, and I want a file > and all its backups to appear next to each other in such a sorted > list. That's exactly why I rename the files the way I do. > Thus, ".1.emacs" is what I want, and ".emacs.1" is a markedly inferior > and unacceptable alternative. That's what I'm referring to by > extension preservation. Unacceptable? You code fails in (ISTM) the more common case of an extensionless file. -Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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)
>
> Thanks! Looking more closely, it's not entirely clear where index
> comes from - what if you already have "a.1.txt". Will you set it
> to 2? Will that then produce a.1.2.txt?
A bit more background: This runs periodically in a setting where the
files in the file list are regenerated in between invocations of this
code. Each time a renaming occurs, the index is incremented (it is
preserved in a file in between invocations). Thus, various
incarnations of "a.txt" would be archived as "a.1.txt", "a.2.txt",
etc. Similarly, copies of ".emacs" would be made as ".1.emacs",
".2.emacs", etc. If "b.1.txt" appeared in the list of files to be
archived, it would be archived as "b.1.1.txt", "b.1.2.txt", etc.
> > Under the new patch, [.emacs] would be renamed to ".emacs.1",
> > gratuitously breaking the extension preservation.
>
> I can see that it breaks the behavior you intended it to have. However,
> I disagree that it broke "extension preservation". Rather, it *provides*
> extension preservation, something that the old code did not do.
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. An
unregistered extension is listed as its own type. Thus files ending
in .txt are listed as type "Text Document", but files ending in
".emacs" are listed as type "emacs" because it's an unregistered
extension.)
I often sort files in the explorer based on type, and I want a file
and all its backups to appear next to each other in such a sorted
list. That's exactly why I rename the files the way I do.
Thus, ".1.emacs" is what I want, and ".emacs.1" is a markedly inferior
and unacceptable alternative. That's what I'm referring to by
extension preservation.
> I also like to point out that the primary objective of the code
> ("archive arbitrary files") is still preserved - it still does that,
> but in different manner. (disclaimer: I don't fully understand the
> index part)
See above.
BTW, I want to echo Brett Cannon's comments about the tone. I've been
a bit testy about this breakage, however, upon reflection, it's clear
that it's not Martin's fault, but rather a shortcoming of the process.
Sorry, Martin. If you or anyone else was offended, please accept my
apologies.
Mike
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 happened to be the guy who made a change that sparked this and he is explaining his thinking behind it (which also happens to mirror my thinking on this whole situation). It could have easily been someone else. On part of this point, I have to agree. Nullum crimen, nulla poena sine praevia lege poenali. 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 oppose a policy which would strictly forbid such changes, and it is just such a policy that Python needs. Bottom line, let's work together as a group to come up with a policy in a civil, positive manner (in a new thread!) and let the result of that decision guide what is done with this fix. Yelling at poor Martin about one patch when we could be spending this effort on trying to discuss what kind of policy we want is not getting us anywhere. I *am* working on that on the side and I hope to have something coherent and whole to present here, in that different thread, very soon. The point, for me, of participating in *this* thread is (A) to continue to keep the issue high-visibility, because in my opinion, compatibility policy is _THE_ issue that python-dev needs to deal with now, (B) to deal with the aforementioned strongly implied opposition to such a policy, and (C) last but not least, to actually get the patch reverted, since, while it is not the larger problem, it is, itself, a problem that needs to be fixed. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 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 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 you change your mind again, and decide >to put this back the way it was? Hear, hear. Python is _not_ stable as a language. I have Java programs that I wrote almost ten years ago which still run perfectly on the latest runtime. There is python software I wrote two years ago which doesn't work right on 2.5, and some of the Python stuff contemporary with that Java code won't even import. I think the problem has less to do with bug fixing than with lack of any clear specifications or documentation about what developers can depend on.You could probably make a case that any change that doesn't fix a crash bug is likely to cause some particular program to behave differently. Absolutely. One of the reasons I'm working on documenting this process is that, of course, *everything* can't be made compatible. The mere act of adding a function or module adds a detectable change in behavior that some program *might* insanely depend on. A clear understanding of what is meant by "backwards compatibility" is equally important to developers trying to future-proof their code as it is to those trying to make sure they don't break code which has been future-proofed. This is a form of social contract, and both sides need to know about it. Take bug 1504333 which lead to a change in sgmllib behavior for angle brackets in quoted attribute values. Did the sgmllib documentation explain that the fixed behavior was incorrect? Might a programmer working with sgmllib have written code that depended on this bug? Do you object to this bug fix? I don't know enough about the specification to say for sure, but I suspect that it is a legitimate bug fix, because sgmllib is implementing an externally-determined spec. In cases where the spec is flagrantly violated, it seems like it should be fixed to adhere to it. For many of these bugs, some people will have written code against the documentation and some people against the implementation or behavior. (In this case, the documentation is vague or conflicting.) I don't think I know how to balance the important of these two classes of users. Some code is going to break the first time they run into the under-specific edge case, some code is going to break when the specification and implementation are clarified. You have to weigh which you think is more likely and which will benefit users the most. If the documentation is vague and conflicting, then it seems likely that a parsing option could be added. I am not advocating perfect, 100% backwards compatibility, merely some standards for what happens when a (potentially) incompatible change is made. For example, you could add a flag to the parser which tweaks the treatment of quoted angle brackets, and warn if the argument is not passed that the default will change in the future (or, better yet, that the argument will be required in the future). Or, you could provide a separate name for invoking the different behavior. I think everyone wants to do the "right thing" by Python's users, but it's not clear what that right thing is. I really think that starting with the "golden rule" would be a good idea. Would Python core developers mind if something analogous in the C runtime changed? How would they cope with it? What kind of feedback would you expect the C compiler or runtime to provide in such a case? Python should do unto others, etc. Could you point out a few such programs that people on python-dev can look at? I think it would be useful to gather some data about the kind of migration pains real users are having. I believe Martin and others are trying to do the right thing. Real data is more likely to convince them than passionate arguments on python-dev. (I assume you're responding to my other comment about my programs not running, even though that's not what you quoted.) I don't think these programs would contribute much to the discussion. I've probably got them archived somewhere, but they were broken circa 2.3 and I don't think I've run them since. I doubt they would make any sense to anyone here, and we would all get into a heated debate as to whether my usage of Python was valid or not (hint: it was *REALLY* gross). In fact, let's back up a step. These programs we
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 cost, and cause more harm than good. They primarily don't appear at the machine of the author of the code. Instead, they appear at the end-user's machine, causing them problems in that they see messages from a software they didn't know they are even running. They all have to chase down the source of the program, only to eventually have the author of the software to tell them that it is safe to ignore this warning (which I believe it is). I specifically got complaints that Python fills Apache log files with garbage warnings. It won't help to issue the warning only once (although that will help in other cases): you then get the warning once per HTTP request (assuming CGI), which still can be a lot of warnings. 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, unless they are right most of the time (which they won't be in this case). > (And, if I thought it'd have any chance of going in, I'd submit a patch > to add a warning and adjust docs/tests/etc... but this issue seems ever > so divided...) You need to find a committer to commit such a change, but otherwise, I think it's a good idea. Contributing is always a good idea. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 unreasonable. I > don't personally find it unreasonable for people to ask for a bit more > of an extended migration path when changes that are being implemented > will cause *silent* changes in behavior. Which is why there is the "Porting" section in the What's New document, which is typically not longer than a page and should list these changes. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 reserved the right to change whatsnew.tex. I believe he does go over Misc/NEWS in doing so. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
[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://twistedmatrix.com/documents/current/api/twisted.python.versions.Version.html#__init__ > > Changing this terminology about Python releases to be more consistent > with other projects would be a a subtle, but good shift towards a > generally better attitude of the expectations of "minor" releases. When PEP 6 was originally written, it said "feature release", and "bug fix release". This was then changed at some point (too lazy to look up subversion log now) to say "major release" and "bugfix release", indicating that the major releases (in the sense of the common expectation) *are* the 2.x releases. At that time, it wasn't clear whether there ever would be a 3.0 release. This is where my understanding of policy comes from: bug fix releases are for bug fixes *only*, major releases can add new features, and correct problems that may break existing applications (using parallel APIs, warnings, etc, as appropriate). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 Python 2.6 that are there now. There's a big difference between that change and this one; that change is 'loud'. It makes noise. It's raising an exception: that exception will either be handled or will propagate up the stack and be noticed somewhere. I *think* (ahem.. I read minds...) the problem people are having with this particular change is the fact that the behavior of this function is being changed in a way that is completely silent. Code written to expect one kind of result are now getting a different kind of result... instead of having an error thrown, a warning given, or something explicit... it's just different now. 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 unreasonable. I don't personally find it unreasonable for people to ask for a bit more of an extended migration path when changes that are being implemented will cause *silent* changes in behavior. It's been very hard for my company to move from 2.3 to 2.4 as a development platform as it is, which we're just barely doing now... for this reason I'm paying a lot more attention to -dev lately to be prepared for 2.6 and beyond. Not everyone has the time to do that.. there's a lot of messages :) And Misc/NEWS is *huge*. Warnings are a very useful mechanism for semi-painless migrations and upgrades... (And, if I thought it'd have any chance of going in, I'd submit a patch to add a warning and adjust docs/tests/etc... but this issue seems ever so divided...) --S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 index
comes from - what if you already have "a.1.txt". Will you set it
to 2? Will that then produce a.1.2.txt?
> This is a little utility that runs on windows that archives arbitrary
> files. index is an integer.
> For index == 1, I want "a.txt" to be renamed to "a.1.txt", and 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.
I can see that it breaks the behavior you intended it to have. However,
I disagree that it broke "extension preservation". Rather, it *provides*
extension preservation, something that the old code did not do.
I also like to point out that the primary objective of the code
("archive arbitrary files") is still preserved - it still does that,
but in different manner. (disclaimer: I don't fully understand the
index part)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 adverse reaction. > > > > 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 wart). > > I just like to point out that I disagree with this classification. The > change is not gratuitous breakage (it's neither gratuitous, nor is it > breakage), nor is it breakage-inducing. > First off, I should say I totally agree with Martin's thinking in this whole matter. If I had been in his situation there is a good chance I would have done what he did based on prior history of when underspecified stuff has what could considered poor behaviour. 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 happened to be the guy who made a change that sparked this and he is explaining his thinking behind it (which also happens to mirror my thinking on this whole situation). It could have easily been someone else. But since Martin does so much work clearing out patches (and we all owe Martin and everyone else who consistently tries to close bugs and patches a HUGE thank you). I am sorry it happened to be Martin, but I also think he has done a great job keeping his composure in this as I would have lost my top at by now had I not been ignoring this thread. And I would hope that people are not explicitly mad at Martin (I suspect people aren't). But from my viewpoint people are getting the point of yelling and that is not going to get us anywhere. Bottom line, let's work together as a group to come up with a policy in a civil, positive manner (in a new thread!) and let the result of that decision guide what is done with this fix. Yelling at poor Martin about one patch when we could be spending this effort on trying to discuss what kind of policy we want is not getting us anywhere. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 run-time? > > Notice that there is already a warning there: the documentation clearly > states that the behavior has changed, and, of course, Misc/NEWS lists > it as changed behavior. 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. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 to the socket addressing wart). > > Please take a look at Misc/NEWS and review all changes that had been > made since 2.5 to find out what other changes are breakage-inducing. 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 Python 2.6 that are there now. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
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 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 connection to an address, and can >> receive, optionally, a timeout. >> >> >> > I opened a new patch (#1676823) with the changes I propose regarding >> > socket.py, because the goal from the two patches are different (my plan >> >> The timeout.diff in this patch was updated to reflect these changes. >> >> If nobody raises objections, I'll commit these changes. >> >> Regards, >> >> -- >> . Facundo >> . >> Blog: http://www.taniquetil.com.ar/plog/ >> PyAr: http://www.python.org/ar/ >> >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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), 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://twistedmatrix.com/documents/current/api/twisted.python.versions.Version.html#__init__ Changing this terminology about Python releases to be more consistent with other projects would be a a subtle, but good shift towards a generally better attitude of the expectations of "minor" releases. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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('renaming %s failed' % f)
Background:
This is a little utility that runs on windows that archives arbitrary
files. index is an integer.
For index == 1, I want "a.txt" to be renamed to "a.1.txt", and 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.
Mike
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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, who wrote "BTW, if it *weren't* for the code breakage, > >>I'd be in favor of doing this." > > > >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 you change your mind again, and decide > >to put this back the way it was? > > Hear, hear. Python is _not_ stable as a language. I have Java programs > that I wrote almost ten years ago which still run perfectly on the latest > runtime. There is python software I wrote two years ago which doesn't work > right on 2.5, and some of the Python stuff contemporary with that Java code > won't even import. I think the problem has less to do with bug fixing than with lack of any clear specifications or documentation about what developers can depend on.You could probably make a case that any change that doesn't fix a crash bug is likely to cause some particular program to behave differently. Take bug 1504333 which lead to a change in sgmllib behavior for angle brackets in quoted attribute values. Did the sgmllib documentation explain that the fixed behavior was incorrect? Might a programmer working with sgmllib have written code that depended on this bug? Do you object to this bug fix? For many of these bugs, some people will have written code against the documentation and some people against the implementation or behavior. (In this case, the documentation is vague or conflicting.) I don't think I know how to balance the important of these two classes of users. Some code is going to break the first time they run into the under-specific edge case, some code is going to break when the specification and implementation are clarified. You have to weigh which you think is more likely and which will benefit users the most. I think everyone wants to do the "right thing" by Python's users, but it's not clear what that right thing is. > >Speaking as a business person, that seems to me... unwise. When I found > >out that this change had been checked in despite all the opposition, my gut > >reaction was, "I guess I can't rely on Python any more", despite 10 years > >of working with it, developing open source software with it, and > >contributing to its development. Because from a *business* perspective, > >this sort of flip-flopping means that moving from one "minor" Python > >version to another is potentially *very* costly. > > And indeed it is. Python's advantages in terms of rapidity of development > have, thus far, made up the difference for me, but it is threatening to > become a close thing. This is a severe problem and something needs to be > done about it. Could you point out a few such programs that people on python-dev can look at? I think it would be useful to gather some data about the kind of migration pains real users are having. I believe Martin and others are trying to do the right thing. Real data is more likely to convince them than passionate arguments on python-dev. > >But as you are so fond of pointing out, there is no "many people". There > >are only individual people. That a majority want it one way, means that > >there is a minority who want it another. If next year, it becomes more > >popular to have it the other way, will we switch again? If a majority of > >people want braces and required type declarations, will we add them? > > And, in fact, there is not even a majority. There is a *perception* of a > majority. There isn't even a *perception* of a majority of Python users, > but a perception of a majority of python-dev readers, who are almost by > definition less risk-averse when it comes to language change than anyone > else! I think you missed the point here. The hypothetical question was not about any particular majority, but rather that regardless of which group you poll, the majority decision may not be the right one. Even a majority of Twised users :-). Jeremy > If we actually care about majorities, let's set up a voting application and > allow Python users to vote on each and every feature, and publicize it each > time such a debate comes up. Here, I'll get it started: > http://jyte.com/cl/python-should-have-a-strict-backward-compatibility-policy-to-guide-its-development > > According to that highly scientific study, at this point in time, "Nobody > disagrees" :). (One in favor, zero against.) > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.pyt
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
"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 with the warning system, but it seems plausible that one
could add to the end of .splitext (before it returns) an optional warning
something like
if not ext and base[0] == '.':
warn("Before 2.6, this would have returned (%s,%s) instead of (%s,%s)"
% (ext, base, base, ext))
where base and ext have the obvious contents. Is this what you want?
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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). See PEP 6. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 code? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 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. Knowing that this was well-defined and documented behavior and having followed this list during previous backward compatibility discussions, I "knew" that there was no way your proposed patch would make it into a minor release because many long-time active developers would rightfully point out that it gratuitously breaks code. In your radical departure from the common-sense approach to code-breaking changes that typically prevails here, you proved me wrong. So now I'm speaking up. FWIW, I agree completely with PJE's and glyph's remarks with respect to expectations of stability, especially in a minor release. Sorry, updating the NEWS file isn't good enough, because as has been amply demonstrated here, many people cannot be bothered to read the documentation. +1 on reverting the patch and not punishing those users who bothered to the documentation or test the corner cases themselves. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
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 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 connection to an address, and can > receive, optionally, a timeout. > > > > I opened a new patch (#1676823) with the changes I propose regarding > > socket.py, because the goal from the two patches are different (my plan > > The timeout.diff in this patch was updated to reflect these changes. > > If nobody raises objections, I'll commit these changes. > > Regards, > > -- > . Facundo > . > Blog: http://www.taniquetil.com.ar/plog/ > PyAr: http://www.python.org/ar/ > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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'd be in favor of doing this." 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 you change your mind again, and decide to put this back the way it was? Hear, hear. Python is _not_ stable as a language. I have Java programs that I wrote almost ten years ago which still run perfectly on the latest runtime. There is python software I wrote two years ago which doesn't work right on 2.5, and some of the Python stuff contemporary with that Java code won't even import. Speaking as a business person, that seems to me... unwise. When I found out that this change had been checked in despite all the opposition, my gut reaction was, "I guess I can't rely on Python any more", despite 10 years of working with it, developing open source software with it, and contributing to its development. Because from a *business* perspective, this sort of flip-flopping means that moving from one "minor" Python version to another is potentially *very* costly. And indeed it is. Python's advantages in terms of rapidity of development have, thus far, made up the difference for me, but it is threatening to become a close thing. This is a severe problem and something needs to be done about it. But as you are so fond of pointing out, there is no "many people". There are only individual people. That a majority want it one way, means that there is a minority who want it another. If next year, it becomes more popular to have it the other way, will we switch again? If a majority of people want braces and required type declarations, will we add them? And, in fact, there is not even a majority. There is a *perception* of a majority. There isn't even a *perception* of a majority of Python users, but a perception of a majority of python-dev readers, who are almost by definition less risk-averse when it comes to language change than anyone else! If we actually care about majorities, let's set up a voting application and allow Python users to vote on each and every feature, and publicize it each time such a debate comes up. Here, I'll get it started: http://jyte.com/cl/python-should-have-a-strict-backward-compatibility- policy-to-guide-its-development According to that highly scientific study, at this point in time, "Nobody disagrees" :). (One in favor, zero against.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
> 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 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 wart). I just like to point out that I disagree with this classification. The change is not gratuitous breakage (it's neither gratuitous, nor is it breakage), nor is it breakage-inducing. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 wart). Please take a look at Misc/NEWS and review all changes that had been made since 2.5 to find out what other changes are breakage-inducing. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
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 connection to an address, and can receive, optionally, a timeout. > I opened a new patch (#1676823) with the changes I propose regarding > socket.py, because the goal from the two patches are different (my plan The timeout.diff in this patch was updated to reflect these changes. If nobody raises objections, I'll commit these changes. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
[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 not deprecated) > asynchronous exception APIs to behave properly. It wasn't possible > then, and it isn't possible now. Ok, I withdraw this SoC project idea. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 of doing this." > > 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 you change your mind again, and decide > to put this back the way it was? > > Speaking as a business person, that seems to me... unwise. When I found > out that this change had been checked in despite all the opposition, my gut > reaction was, "I guess I can't rely on Python any more", despite 10 years > of working with it, developing open source software with it, and > contributing to its development. Because from a *business* perspective, > this sort of flip-flopping means that moving from one "minor" Python > version to another is potentially *very* costly. > > 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 now believe that this should be done *despite* having been >> documented and tested (which, as you can see, was documented >> and tested only match the implemented behavior). That it keeps >> popping up is proof that the old behavior is deemed incorrect >> by many people. > > But as you are so fond of pointing out, there is no "many people". There > are only individual people. That a majority want it one way, means that > there is a minority who want it another. If next year, it becomes more > popular to have it the other way, will we switch again? If a majority of > people want braces and required type declarations, will we add them? > > After all, there is *substantial* support for some proposals along those > lines! > > Yet, one of the appeals of Python is that it has some sense of what is > "right" or "wrong", and some explanation for that rightness or wrongness > that doesn't change with the ebb and flow of popular opinion and the > current population of a mailing list. > > IMO, Python is not -- or at least should not be -- a popularity contest. > > >>> So reject it, or propose to add a new API. >> Neither is a solution. Rejecting it means it will keep popping up >> forever. > > Like requests to remove whitespace sensitivity and add braces? > > That a request may keep popping up forever is not an argument for changing > it NOW. As Tim put it, "Never is often better than *right* now," and it > seems to me that this is *exactly* the sort of change for which that saying > was coined. > > >> The amount of Python code yet to be written is hopefully larger >> than the code already written (paraphrasing Guido), so in the long run, >> it should show the right behavior, not the historical one. > > Sure - but by that argument, the amount of code that will be written in 3.0 > or 3.1 is larger still, and if this behavior's been mostly okay for 9+ > years, then fixing it in a year or two should be quite prompt, if you want > to look at the historical scale. > > In any case, my main concern about this change isn't whether it's right or > wrong -- it's about whether Python provides a stable platform for software > development with reasonable migration paths. *This* change won't actually > hurt *me* -- but what will the next change be? Must everyone who wants > some form of stability maintain a constant watch over Python's source changes? > > I gather that your answer is "yes", and that's what disturbs me here. > The impact of this one little change certainly isn't the only issue at stake here. But as Mr. Creosote knows, even one little "wafer thin" change can lead to a chaotic transformation. Since 2.0 serious efforts have been made to maintain, and even promote, the stability and backwards compatibility of Python. This has benefited the language. 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. Now, you might feel (as Guido does) that it doesn't matter what people write in their blogs, but I personally want people to perceive Python as a language whose development is carefully managed. Consequently I am disturbed when a change of this nature is made and it becomes apparent that there is no consensus for it. 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-induc
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 you change your mind again, and decide > to put this back the way it was? I'm still wondering what policy you think I have violated. If we both agree that the old behavior was erroneous, then I cannot understand why you want to see the patch reverted. Nobody has so far proposed any alternative fix (not even as a specification, let alone as a specific patch - just with some hinting), and the majority of the people polled thought that it ought to be fixed. > 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 run-time? Notice that there is already a warning there: the documentation clearly states that the behavior has changed, and, of course, Misc/NEWS lists it as changed behavior. So you can certainly discover *now* that the behavior has changed: read the documentation. If you want to discover it without reading documentation, we can discuss that. > But as you are so fond of pointing out, there is no "many people". There > are only individual people. That a majority want it one way, means that > there is a minority who want it another. If next year, it becomes more > popular to have it the other way, will we switch again? This is highly theoretical. > If a majority of > people want braces and required type declarations, will we add them? PEP 3099 explicitly rules out the introduction of braces. As for type declarations: it would require a PEP, being a major feature. It then depends on the details. PEP 245 was rejected by BDFL pronouncement. This is how things are ultimately decided: by BDFL pronouncement. > Yet, one of the appeals of Python is that it has some sense of what is > "right" or "wrong", and some explanation for that rightness or wrongness > that doesn't change with the ebb and flow of popular opinion and the > current population of a mailing list. In this specific case, it seems that people had agree on "right" for a long time, and had just accepted that the current implementation is "wrong". You also agree to that, and many other long-time Python contributors have agreed. So as long as those people are around, it is unlikely that they change their minds again on this specific question. >>> So reject it, or propose to add a new API. >> Neither is a solution. Rejecting it means it will keep popping up >> forever. > > Like requests to remove whitespace sensitivity and add braces? No, unlike that. See above, plus the people contributing to Python believe that the current behavior is right (although the view on using tabs-vs-spaces has changed over time). In this case it's different: all long-time contributors seem to agree that the new behavior is the desirable one, on a green field. > In any case, my main concern about this change isn't whether it's right or > wrong -- it's about whether Python provides a stable platform for software > development with reasonable migration paths. *This* change won't actually > hurt *me* -- but what will the next change be? Must everyone who wants > some form of stability maintain a constant watch over Python's source changes? > > I gather that your answer is "yes", and that's what disturbs me here. No. I firmly believe that even with this change, Python provides "some form of stability". All the alternatives that had been proposed, except for the "never" variant, provide less stability. This is the most stable patch to solve the problem that I could think of. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
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 can specifically address these points:
1. A thread can throw a ThreadDeath exception almost anywhere. All
synchronized methods and blocks would have to be studied in
great
detail, with this in mind.
2. A thread can throw a second ThreadDeath exception while cleaning
up
from the first (in the catch or finally clause). Cleanup would
have
to repeated till it succeeded. The code to ensure this would be
quite
complex.
Clearly, a thread need to have its finally blocks performed in response
to a cancellation request. These issues are real, however, they apply
to any asynchronous exception, not just to thread cancellation.
To be sure, the problem does apply to all asynchronous exceptions.
That's why it is generally understood that a program which has received
an asynchronous exception cannot continue.
In Python, we already have an asynchronous exception:
KeyboardInterrupt.
This suffers from the same problems: a KeyboadInterrupt also can occur
at any point, interrupting code in the middle of its finally-blocks.
The other exception that is nearly-asynchronous is OutOfMemoryError,
which can occur at nearly any point (but of course, never occurs in
practice).
KeyboardInterrupt and MemoryError share a common feature which forced
thread termination does not: nobody reasonably expects the program to
keep running after they have been raised. Indeed, programs are written
with the expectation that MemoryError will never occur, and if it does,
the user is not surprised to find them in an inconsistent state. In any
situation where a MemoryError may reasonably be expected - that is to
say, a specific, large allocation of a single block of memory - it can
be trapped as if it were not asynchronous.
Long-running Python programs which expect to need to do serious clean-up
in the face of interrupts, in fact, block KeyboardInterrupt by
registering their own interrupt handlers (Zope, Twisted).
Developers who think they want thread cancellation inevitably believe
they can, if they are "sufficiently careful", implement operating-
system-like scheduling features by starting arbitrary user code and then
providing "terminate", "pause", and "resume" commands. That was the
original intent of these (now removed) Java APIs, and that is why they
were removed: you can't do this. It's impossible.
Asynchronous exceptions are better than immediate termination because
they allow for code which is allocating scarce or fragile resources to
have a probabilistically better chance of cleaning up. However, nobody
writes code like this:
def addSomeStuff(self, volume, mass):
self.volume += volume
try:
self.mass += mass
except AsynchronousInterrupt:
while 1:
try:
self.volume -= volume
break
except AsynchronousInterrupt:
pass
and nobody is going to start if the language provides thread
termination. Async-Exception-Safe Python code is, and will be, as rare
as POSIX Async-Safe functions, which means at best you will be able to
call a thread cancellation API and have it _appear_ to work in some
circumstances. In any system which uses Python code not explicitly
designed to support asynchronous exceptions (let's say, the standard
library) it will be completely impossible to write correct code.
I'm not a big fan of shared-state-threading, but it does allow for a
particular programming model. Threading provides you some guarantees.
You can't poke around on the heap, but you know that your stack, and
your program counter, are inviolate. You can reason about, if not quite
test, the impact of sharing a piece of state on the heap; its
destructive methods need to be synchronized along with the read methods
that interact with it.
Asynchronous exceptions destroy all hope of sanity. Your program might
suddenly perform a nonlocal exit _anywhere_ except, maybe, inside a
"finally" block. This literally encourages some people that program in
environments where asynchronous exceptions are possible (.NET, in
particular) to put huge chunks of application code inside finally
blocks. They generally look like this:
try {}
finally {
// entire application here
}
because that is really the only way you can hope to write code that will
function robustly in such an environment.
So yes, it would be good if Python's exception handling supported
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 res
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 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 you change your mind again, and decide to put this back the way it was? Speaking as a business person, that seems to me... unwise. When I found out that this change had been checked in despite all the opposition, my gut reaction was, "I guess I can't rely on Python any more", despite 10 years of working with it, developing open source software with it, and contributing to its development. Because from a *business* perspective, this sort of flip-flopping means that moving from one "minor" Python version to another is potentially *very* costly. 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 now believe that this should be done *despite* having been >documented and tested (which, as you can see, was documented >and tested only match the implemented behavior). That it keeps >popping up is proof that the old behavior is deemed incorrect >by many people. But as you are so fond of pointing out, there is no "many people". There are only individual people. That a majority want it one way, means that there is a minority who want it another. If next year, it becomes more popular to have it the other way, will we switch again? If a majority of people want braces and required type declarations, will we add them? After all, there is *substantial* support for some proposals along those lines! Yet, one of the appeals of Python is that it has some sense of what is "right" or "wrong", and some explanation for that rightness or wrongness that doesn't change with the ebb and flow of popular opinion and the current population of a mailing list. IMO, Python is not -- or at least should not be -- a popularity contest. >>So reject it, or propose to add a new API. > >Neither is a solution. Rejecting it means it will keep popping up >forever. Like requests to remove whitespace sensitivity and add braces? That a request may keep popping up forever is not an argument for changing it NOW. As Tim put it, "Never is often better than *right* now," and it seems to me that this is *exactly* the sort of change for which that saying was coined. >The amount of Python code yet to be written is hopefully larger >than the code already written (paraphrasing Guido), so in the long run, >it should show the right behavior, not the historical one. Sure - but by that argument, the amount of code that will be written in 3.0 or 3.1 is larger still, and if this behavior's been mostly okay for 9+ years, then fixing it in a year or two should be quite prompt, if you want to look at the historical scale. In any case, my main concern about this change isn't whether it's right or wrong -- it's about whether Python provides a stable platform for software development with reasonable migration paths. *This* change won't actually hurt *me* -- but what will the next change be? Must everyone who wants some form of stability maintain a constant watch over Python's source changes? I gather that your answer is "yes", and that's what disturbs me here. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
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 > handler) may apply. Two already working schemes, that are similar, comes to my mind. One is signals in Linux/Unix, where you can send SIGTERM, and the process can handle it and do whatever it takes. But also you can send SIGKILL, which can not be blocked. The other is microprocessors, where you have interrupts, and when the interrupt is received, you disable it (are there processors that support "reentrant" interrupts? I don't know of any, but I'm no specialist here). To me, is natural this behaviour: One can send ThreadDeath to the thread, and it can handle it or no. If not, it dies. If yes, it does some stuff and dies. But if I send a second ThreadDeath to the same thread, when it's still "dying", for me it's ok to receive an answer like "Ok, ok, I heard you, I'm on it". But, in that scenario, should be a way to say to the thread "Die, die now, no matter what"? Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
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: > >1. A thread can throw a ThreadDeath exception almost anywhere. All > synchronized methods and blocks would have to be studied in great > detail, with this in mind. > >2. A thread can throw a second ThreadDeath exception while cleaning up > from the first (in the catch or finally clause). Cleanup would have > to repeated till it succeeded. The code to ensure this would be quite > complex. Clearly, a thread need to have its finally blocks performed in response to a cancellation request. These issues are real, however, they apply to any asynchronous exception, not just to thread cancellation. In Python, we already have an asynchronous exception: KeyboardInterrupt. This suffers from the same problems: a KeyboadInterrupt also can occur at any point, interrupting code in the middle of its finally-blocks. The other exception that is nearly-asynchronous is OutOfMemoryError, which can occur at nearly any point (but of course, never occurs in practice). So yes, it would be good if Python's exception handling supported 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 handler) may apply. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
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.4.2/docs/guide/misc/threadPrimitiveDeprecation.html > >I responded to that. I got the impression reading that page that the killed >thread doesn't regain control so it can't clean up its potentially >inconsistent data structures. The second question on the page: Couldn't I just catch the ThreadDeath exception and fix the damaged object? Addresses this. >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: 1. A thread can throw a ThreadDeath exception almost anywhere. All synchronized methods and blocks would have to be studied in great detail, with this in mind. 2. A thread can throw a second ThreadDeath exception while cleaning up from the first (in the catch or finally clause). Cleanup would have to repeated till it succeeded. The code to ensure this would be quite complex. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
>> 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. I got the impression reading that page that the killed thread doesn't regain control so it can't clean up its potentially inconsistent data structures. 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. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
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/threadPrimitiveDeprecation.html Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Status of thread cancellation
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.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pypy's interpreter/highlevel backend features
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 interesting. I'll read it later. BTW, I downloaded it ok. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pypy's interpreter/highlevel backend features
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_Prototypes-interim-2007-03-12.pdf > > As of this moment, this is not loading. -- times out Works for me now, in the last days there were routing problems with the provider, maybe that was it. Cheers, Carl Friedrich ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
