Re: [Python-Dev] Let's stop eating exceptions in dict lookup
Raymond Hettinger wrote: Armin Rigo wrote: [...] At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously on the tests I try to time, and even going into an infinite loop consuming all my memory - since the NFS sprint. Am I allowed to be grumpy here, and repeat that speed should not be used to justify bugs? I'm proposing a bug fix, I honestly don't care about 0.5% of speed. If it is really 0.5%, then we're fine. Just remember that PyStone is an amazingly uninformative and crappy benchmark. Which sadly doesn't distinguish it particularly, since all benchmarks tend towards the uninformative and crappy. The justify bugs terminology is pejorative and inaccurate. It is clear that the current dict behavior was a concious design decision and documented as such. Perhaps the decision sucked and should be changed, but it is not a bug. and I consider myself an everyday Python user, Something may have been lost in translation. Using it every day is not the same as being an everyday user ;-) There is no doubt that you routinely stress the language in ways ways that are not at all commonplace. Just the same, I think Armin's point that the change in behavior might induce breakage in working programs is one we need to consider carefully, even though programs relying on the current behaviour might reasonably be considered broken (for some value of broken). All I'm asking is that there be a well thought-out assessment of whether the original design decision was struck the appropriate balance between practicality I think the discussion has touched all the major points, but this won't stave off the squeals of anguish form those running programs that break under 2.5. There are some similarities between this change and the (2.0?) change that stopped socket.socket() from accepting two arguments. IMHO I think we should accept that the behaviour needs to change and be prepared for a few anguished squeals. FWIW I suspect they will be even fewer than anticipated. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Love me, love my blog http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] Let's stop eating exceptions in dict lookup
Anthony Baxter [EMAIL PROTECTED] writes: On Friday 02 June 2006 02:21, Jack Diederich wrote: The CCP Games CEO said they have trouble retaining talent from more moderate latitudes for this reason. 18 hours of daylight makes them a bit goofy and when the Winter Solstice rolls around they are apt to go quite mad. Obviously they need to hire people who are already crazy. I think they already did! :) not-naming-any-names-ly, Anthony me-neither-ly y'rs mwh -- Look I don't know. Thankyou everyone for arguing me round in circles. No need for thanks, ma'am; that's what we're here for. -- LNR Michael M Mason, cam.misc ___ 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] Let's stop eating exceptions in dict lookup
On Wed, May 31, 2006 at 09:10:47PM -0400, Tim Peters wrote: [Martin Blais] I'm still looking for a benchmark that is not amazingly uninformative and crappy. I've been looking around all day, I even looked under the bed, I cannot find it. I've also been looking around all day as well, even looked for it shooting out of the Iceland geysirs, of all places--it's always all day out here it seems, day and day-- and I still can't find it. (In the process however, I found Thule beer and strangely dressed vikings, which makes it all worthwhile.) For those who don't know, Martin stayed on in Iceland after the NFS sprint. He shows clear signs above of developing photon madness. http://www.timeanddate.com/worldclock/astronomy.html?n=211 Where that says sunset, don't read dark -- it just means the top of the sun dips a bit below the horizon for a few hours. It never gets dark this time of year. If you haven't experienced this, no explanation can convey the other-worldly sense of it. The CCP Games CEO said they have trouble retaining talent from more moderate latitudes for this reason. 18 hours of daylight makes them a bit goofy and when the Winter Solstice rolls around they are apt to go quite mad. -Jack ___ 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] Let's stop eating exceptions in dict lookup
[Martin Blais] I'm still looking for a benchmark that is not amazingly uninformative and crappy. I've been looking around all day, I even looked under the bed, I cannot find it. I've also been looking around all day as well, even looked for it shooting out of the Iceland geysirs, of all places--it's always all day out here it seems, day and day-- and I still can't find it. (In the process however, I found Thule beer and strangely dressed vikings, which makes it all worthwhile.) For those who don't know, Martin stayed on in Iceland after the NFS sprint. He shows clear signs above of developing photon madness. http://www.timeanddate.com/worldclock/astronomy.html?n=211 Where that says sunset, don't read dark -- it just means the top of the sun dips a bit below the horizon for a few hours. It never gets dark this time of year. If you haven't experienced this, no explanation can convey the other-worldly sense of it. Combined with Iceland's astonishing and beautiful geography, a North American boy (like Martin or me) could swear they were transported to a different planet. It's one I'd love to visit again, but back home for a few days now I still turn the lights off for about half an hour each night and just sit here cherishing darkness :-) ___ 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] Let's stop eating exceptions in dict lookup
Hi Fredrik, On Tue, May 30, 2006 at 07:48:50AM +0200, Fredrik Lundh wrote: since abc.find(, 0) == 0, I would have thought that a program that searched for an empty string in a loop wouldn't get anywhere at all. Indeed. And when this bug was found in the program in question, a natural fix was to add 1 to the start position if the searched string was empty, which used to ensure that the loop terminates. A bientot, Armin ___ 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] Let's stop eating exceptions in dict lookup
Tim Peters wrote: abc.count(, 100) 1 uabc.count(, 100) 1 which is the same as abc[100:].count() 1 abc.find(, 100) 100 uabc.find(, 100) 100 today, although the idea that find() can return an index that doesn't exist in the string is particularly jarring. Since we also have: abc.rfind(, 100) 3 uabc.rfind(, 100) 3 it's twice as jarring that searching from the right finds the target at a _smaller_ index than searching from the left. well, string[pos:pos+len(substring)] == substring is true in both cases. would abc.find(, 100) == 3 be okay? or should we switch to treating the optional start and end positions as return value boundaries (used to filter the result) rather than slice directives (used to process the source string before the operation)? it's all trivial to implement, and has no performance implications, but I'm not sure what the consensus really is... /F ___ 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] Let's stop eating exceptions in dict lookup
On 5/29/06, Raymond Hettinger [EMAIL PROTECTED] wrote: If it is really 0.5%, then we're fine. Just remember that PyStone is an amazingly uninformative and crappy benchmark. I'm still looking for a benchmark that is not amazingly uninformative and crappy. I've been looking around all day, I even looked under the bed, I cannot find it. I've also been looking around all day as well, even looked for it shooting out of the Iceland geysirs, of all places--it's always all day out here it seems, day and day-- and I still can't find it. (In the process however, I found Thule beer and strangely dressed vikings, which makes it all worthwhile.) cheers, ___ 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] Let's stop eating exceptions in dict lookup
From: Armin Rigo [EMAIL PROTECTED] I've finally come around to writing a patch that stops dict lookup from eating all exceptions that occur during lookup, like rare bugs in user __eq__() methods. Is there a performance impact? Raymond ___ 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] Let's stop eating exceptions in dict lookup
On 5/29/06, Armin Rigo [EMAIL PROTECTED] wrote: Hi all, I've finally come around to writing a patch that stops dict lookup from eating all exceptions that occur during lookup, like rare bugs in user __eq__() methods. After another 2-hours long debugging session that turned out to be caused by that, I had a lot of motivation. http://python.org/sf/1497053 The patch doesn't change the PyDict_GetItem() interface, which is the historical core of the problem. It works around this issue by just moving the exception-eating bit there instead of in lookdict(), so it gets away with changing only dictobject.c (plus ceval.c's direct usage of ma_lookup for LOAD_GLOBAL). The benefit of this patch is that all other ways to work with dicts now correctly propagate exceptions, and this includes all the direct manipulation from Python code (including 'x=d[key]'). The reason I bring this up here is that I'm going to check it in 2.5, unless someone seriously objects. +1, as long as (as you seem to imply) PyDict_GetItem() still swallows all exceptions. About the objection we need a better fix, PyDict_GetItem() should really be fixed and all its usages changed: this would be good, and also require some careful compatibility considerations, and quite some work in total; it would also give a patch which is basically a superset of mine, so I don't think I'm going in the wrong direction there. Fixing PyDict_GetItem() is a py3k issue, I think. Until then, there are way too many uses. I wouldn't be surprised if after INCREF and DECREF it's the most commonly used C API method... -- --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] Let's stop eating exceptions in dict lookup
Hi Guido, On Mon, May 29, 2006 at 12:34:30PM -0700, Guido van Rossum wrote: +1, as long as (as you seem to imply) PyDict_GetItem() still swallows all exceptions. Yes. Fixing PyDict_GetItem() is a py3k issue, I think. Until then, there are way too many uses. I wouldn't be surprised if after INCREF and DECREF it's the most commonly used C API method... Alternatively, we could add a new C API function, and gradually replace PyDict_GetItem() uses with the the new one. I can't think of an obvious name, though... Maybe code should just start using PyMapping_GetItem() instead. It's not incredibly slower than PyDict_GetItem(), at least in the non-KeyError case. A bientot, Armin ___ 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] Let's stop eating exceptions in dict lookup
Hi Raymond, On Mon, May 29, 2006 at 12:20:44PM -0700, Raymond Hettinger wrote: I've finally come around to writing a patch that stops dict lookup from eating all exceptions that occur during lookup, like rare bugs in user __eq__() methods. Is there a performance impact? I believe that this patch is good anyway, because I consider my (and anybody's) debugging hours worth more than a few seconds of a long-running process. You get *really* obscure bugs this way. I would also point out that this is the kind of feature that should not be traded off for performance, otherwise we'd loose much of the point of Python. IMHO. As it turns out, I measured only 0.5% performance loss in Pystone. A bientot, Armin ___ 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] Let's stop eating exceptions in dict lookup
Armin Rigo wrote: As it turns out, I measured only 0.5% performance loss in Pystone. umm. does Pystone even call lookdict? /F ___ 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] Let's stop eating exceptions in dict lookup
On Mon, May 29, 2006 at 12:20:44PM -0700, Raymond Hettinger wrote: I've finally come around to writing a patch that stops dict lookup from eating all exceptions that occur during lookup, like rare bugs in user __eq__() methods. Is there a performance impact? I believe that this patch is good anyway, because I consider my (and anybody's) debugging hours worth more than a few seconds of a long-running process. You get *really* obscure bugs this way. I would also point out that this is the kind of feature that should not be traded off for performance, otherwise we'd loose much of the point of Python. IMHO. As it turns out, I measured only 0.5% performance loss in Pystone. Please run some better benchmarks and do more extensive assessments on the performance impact. The kind of obscure bug you're trying to kill does not affect 99.9% of Python users; however, loss of performance will affect everyone. This is arguably the most actively exercised part of the Python and should not be changed without carefully weighing purity vs practicality. FWIW, I applied a similar patch to set objects in Py2.5 so that they wouldn't eat exceptions. So, I'm truly sympathetic to the cause. However, dicts are much more critical. There needs to be a careful judgement based on measurements and assessments of whether there are real benefits for everyday Python users. Raymond ___ 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] Let's stop eating exceptions in dict lookup
Hi Raymond, On Mon, May 29, 2006 at 02:02:25PM -0700, Raymond Hettinger wrote: Please run some better benchmarks and do more extensive assessments on the performance impact. At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously on the tests I try to time, and even going into an infinite loop consuming all my memory - since the NFS sprint. Am I allowed to be grumpy here, and repeat that speed should not be used to justify bugs? I'm proposing a bug fix, I honestly don't care about 0.5% of speed. With a benchmark that passed, and that heavily uses instance and class attribute look-ups (richards), I don't even see any relevant difference. and assessments of whether there are real benefits for everyday Python users. It would have saved me two hours-long debugging sessions, and I consider myself an everyday Python user, so yes, I think so. Grumpy-ly yours, Armin ___ 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] Let's stop eating exceptions in dict lookup
Armin Rigo wrote: At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously on the tests I try to time, and even going into an infinite loop consuming all my memory - since the NFS sprint. Am I allowed to be grumpy here, and repeat that speed should not be used to justify bugs? not unless you can produce some code. unfounded accusations don't belong on this list (it's not like the sprinters didn't test the code on a whole bunch of platforms), and neither does lousy benchmarks (why are you repeating the 0.5% figure when pystone doesn't even test non-string dictionary behaviour? PyString_Eq cannot fail...) /F ___ 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] Let's stop eating exceptions in dict lookup
Re-hi,
On Mon, May 29, 2006 at 11:34:28PM +0200, Armin Rigo wrote:
At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously on
the tests I try to time, and even going into an infinite loop consuming
all my memory
Ah, it's a corner case of str.find() whose behavior just changed.
Previously, 'abc'.find('', 100) would return -1, and now it returns 100.
Just to confuse matters, the same test with unicode returns 100, and has
always done so in the past. (Oh well, one of these again...)
So, we need to decide which behavior is right. One could argue that
the current 2.5 HEAD now has a consistent behavior, so it could be kept;
but there is an opposite argument as well, which is that some existing
programs like the one I was testing are now thrown into annoying
infinite loops because str.find() never returns -1 any more, even with
larger and larger start arguments. I believe that it's a pattern that
could be common in string-processing scripts, trying to match substrings
at various points in a string trusting that str.find() will eventually
return -1. It's harder to think of a case where a program previously
relied on unicode.find('',n) never returning -1. Also, introducing a
new way for programs to be caught in an infinite loop is probably not a
good idea.
Hum, my apologies for my grumpy comments about the NFS sprint. At
least, the unification of the string and unicode algorithm that was
started there is a good move, also because it exposes pre-existing
inconsistencies.
A bientot,
Armin.
___
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] Let's stop eating exceptions in dict lookup
Armin Rigo wrote:
Ah, it's a corner case of str.find() whose behavior just changed.
Previously, 'abc'.find('', 100) would return -1, and now it returns 100.
Just to confuse matters, the same test with unicode returns 100, and has
always done so in the past. (Oh well, one of these again...)
So, we need to decide which behavior is right. One could argue that
the current 2.5 HEAD now has a consistent behavior, so it could be kept;
but there is an opposite argument as well, which is that some existing
programs like the one I was testing are now thrown into annoying
infinite loops because str.find() never returns -1 any more, even with
larger and larger start arguments. I believe that it's a pattern that
could be common in string-processing scripts, trying to match substrings
at various points in a string trusting that str.find() will eventually
return -1.
well, the empty string is a valid substring of all possible strings
(there are no null strings in Python). you get the same behaviour
from slicing, the in operator, replace (this was discussed on the
list last week), count, etc.
if you're actually searching for a *non-empty* string, find() will
always return -1 sooner or later.
Hum, my apologies for my grumpy comments about the NFS sprint. At
least, the unification of the string and unicode algorithm that was
started there is a good move, also because it exposes pre-existing
inconsistencies.
here's my current favourite:
abc.count(, 100)
-96
/F
___
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] Let's stop eating exceptions in dict lookup
Hi Fredrik, On Tue, May 30, 2006 at 12:01:46AM +0200, Fredrik Lundh wrote: not unless you can produce some code. unfounded accusations don't belong on this list (it's not like the sprinters didn't test the code on a whole bunch of platforms), and neither does lousy benchmarks (why are you repeating the 0.5% figure when pystone doesn't even test non-string dictionary behaviour? PyString_Eq cannot fail...) Sorry, I do apologize for my wording. I must admit that I was a bit apalled by the amount of reference leaks that Michael had to fix after the sprint, so jumped to conclusions a bit too fast when I saw by 1GB laptop swap after less than a minute. See my e-mail, which crossed yours, for the explanation. The reason I did not quote examples involving non-string dicts is that my patch makes the non-string case simpler, so -- as I expected, and as I have now measured -- marginally faster. All in all it's hard to say if there is a global consistent performance change. At this point I'd rather like to spend my time more interestingly; this might be by defending my point of view that very minor performance hits should not get in the way of fixes that avoid very obscure bugs, even only occasionally-occuring but still very obscure bugs. A bientot, Armin. ___ 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] Let's stop eating exceptions in dict lookup
Armin Rigo wrote: Hi Raymond, On Mon, May 29, 2006 at 02:02:25PM -0700, Raymond Hettinger wrote: Please run some better benchmarks and do more extensive assessments on the performance impact. At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously on the tests I try to time, and even going into an infinite loop consuming all my memory - since the NFS sprint. Am I allowed to be grumpy here, and repeat that speed should not be used to justify bugs? I'm proposing a bug fix, I honestly don't care about 0.5% of speed. If it is really 0.5%, then we're fine. Just remember that PyStone is an amazingly uninformative and crappy benchmark. The "justify bugs" terminology is pejorative and inaccurate. It is clear that the current dict behavior was a concious design decision and documented as such. Perhaps the decision sucked and should be changed, but it is not a bug. and I consider myself an everyday Python user, Something may have been lost in translation. Using it every day is not the same as being an everyday user ;-) There is no doubt that you routinely stress the language in ways ways that are not at all commonplace. All I'm asking is that there be a well thought-out assessment of whether the original design decision was struck the appropriate balance between practicality Raymond ___ 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] Let's stop eating exceptions in dict lookup
Hi Fredrik, On Tue, May 30, 2006 at 12:23:04AM +0200, Fredrik Lundh wrote: well, the empty string is a valid substring of all possible strings (there are no null strings in Python). you get the same behaviour from slicing, the in operator, replace (this was discussed on the list last week), count, etc. if you're actually searching for a *non-empty* string, find() will always return -1 sooner or later. I know this. These corner cases are debatable and different answers could be seen as correct, as I think is the case for find(). My point was different: I was worrying that the recent change in str.find() would needlessly send existing and working programs into infinite loops, which can be a particularly bad kind of failure for some applications. At least, it gave a 100% performance loss on the benchmark I was trying to run :-) A bientot, Armin. ___ 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] Let's stop eating exceptions in dict lookup
Raymond Hettinger wrote:
If it is really 0.5%, then we're fine. Just remember that PyStone is an
amazingly uninformative and crappy benchmark.
Since Armin seems to not like having to justify his patch with any
performance testing, I wrote a handful of dict insertion exercises and
could find no real performance impact. In the case of an exception, it
was much faster, but that is because it is not inserting anything into
the dictionary.
IOW if it is a bad change in behavior. Previously, the exception was
swallowed and it was assumed to be a new key despite the exception. This
is an obscure use case that could creep up it's ugly head.
class K(int):
def __cmp__(self, o): raise Exception()
d = {}
for i in xrange(10):
d[K()] = i
for k in d.keys():
print d[k]
Despite the incomparability, this throws no error in previous versions
and the dict is still usable for the expected purpose.
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
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] Let's stop eating exceptions in dict lookup
Fredrik Lundh wrote: well, the empty string is a valid substring of all possible strings (there are no null strings in Python). you get the same behaviour from slicing, the in operator, replace (this was discussed on the list last week), count, etc. Although Tim pointed out that replace() only regards n+1 empty strings as existing in a string of lenth n. So for consistency, find() should only find them in those places, too. -- 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] Let's stop eating exceptions in dict lookup
On 5/29/06, Greg Ewing [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: well, the empty string is a valid substring of all possible strings (there are no null strings in Python). you get the same behaviour from slicing, the in operator, replace (this was discussed on the list last week), count, etc. Although Tim pointed out that replace() only regards n+1 empty strings as existing in a string of lenth n. So for consistency, find() should only find them in those places, too. And abc.count() should return 4. -- --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] Let's stop eating exceptions in dict lookup
[Greg Ewing] Although Tim pointed out that replace() only regards n+1 empty strings as existing in a string of lenth n. So for consistency, find() should only find them in those places, too. [Guido] And abc.count() should return 4. And it does, but too much context was missing in Greg's reply to make sense of his comment. In context Greg was seeming to say that abc.count(, 100) should return 0, and abc.find(, 100) should return -1, since the only empty substrings of abc are at slices 0:0, 1:1, 2:2 and 3:3. In fact we have abc.count(, 100) 1 uabc.count(, 100) 1 abc.find(, 100) 100 uabc.find(, 100) 100 today, although the idea that find() can return an index that doesn't exist in the string is particularly jarring. Since we also have: abc.rfind(, 100) 3 uabc.rfind(, 100) 3 it's twice as jarring that searching from the right finds the target at a _smaller_ index than searching from the left. ___ 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] Let's stop eating exceptions in dict lookup
[Armin Rigo] ... ... Am I allowed to be grumpy here, and repeat that speed should not be used to justify bugs? As a matter of fact, you are. OTOH, nobody at the sprint made that argument, so nobody actually feels shame on that count :-) I apologize for the insufficiently reviewed exception-rework patch anyway. The massive try/raise/except slowdown in 2.5a2 (compared to 2.4.3) was depressing and surprising, and figuring it out repairing it consumed various peoples' time across the whole week. By the time Saturday came around, I was fried enough that well, people have hacked on this all week, the slowdown finally got replaced by a speedup, and all the tests pass -- enough already, let's go home! ruled. So, as everyone suspected all along, it's Neal's fault for not running his refleak test more often ;-) ... It would have saved me two hours-long debugging sessions, and I consider myself an everyday Python user, so yes, I think so. I'll try to review your patch carefully Tuesday, but I'm willing to accept a slowdown for this too (although from a quick look I doubt there's a measurable one, and your approach is wholly sane). ___ 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] Let's stop eating exceptions in dict lookup
Guido van Rossum wrote: well, the empty string is a valid substring of all possible strings (there are no null strings in Python). you get the same behaviour from slicing, the in operator, replace (this was discussed on the list last week), count, etc. Although Tim pointed out that replace() only regards n+1 empty strings as existing in a string of lenth n. So for consistency, find() should only find them in those places, too. depends on how you interpret the reference to slices in the docs. abc[100:] is an empty string, and so is abc[100:100]. And abc.count() should return 4. it does, and has always done (afaik). abc.count(, 100) did use to return -96, though, which is hard to explain in terms of anything else. /F ___ 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] Let's stop eating exceptions in dict lookup
Armin Rigo wrote: I know this. These corner cases are debatable and different answers could be seen as correct, as I think is the case for find(). My point was different: I was worrying that the recent change in str.find() would needlessly send existing and working programs into infinite loops, which can be a particularly bad kind of failure for some applications. since abc.find(, 0) == 0, I would have thought that a program that searched for an empty string in a loop wouldn't get anywhere at all. /F ___ 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
