[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>.