[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>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4