[Python-Dev] Deprecating string exceptions

2002年3月28日 00:43:57 -0500

[Fred L. Drake, Jr.]
> Yes, but in practice, the strings that were used for exceptions were
> simple in this way.

When I first starting using Python, I believed the exception string had to
be named 'error'. Timmy see, Timmy do. Guido scowl, Timmy start using
nested tuple exceptions and break Guido's code. Heh heh.
> I don't know whether there's a #define that controls the use of
> interning; I can't imaging that anyone would want to use it.

It's INTERN_STRINGS. I'd like to get rid of it. Ditto
DONT_SHARE_SHORT_STRINGS. Ditto CACHE_HASH and COUNT_ALLOCS, for that
matter. BTW, all four are used in PyString_FromStringAndSize -- and I'm
sure we routinely test all 16 preprocessor variations <wink>.
[Barry]
>> So, yes the simple example I gave will work, but the more general
>> concept, that string exceptions cannot guaranteed to be caught by
>> value, still holds.

> Agreed. But that's always been well-known, and probably even
> documented. ;-)

It's not that well-known, and because consts are "effectively" interned on a
per-codeblock basis, it's easy to fool yourself into believing they're
compared by value when writing simple test cases. For example, put this in
a file and run it:
try:
 raise "Woo hoo!"
except "Woo hoo!":
 print "caught it"
All instances of a given string within a single code block map to the same
CO_CONSTS entry, so this *appears* to work fine, despite that it doesn't
work at all <wink>.