[Python-Dev] Deprecating string exceptions

[Tim Peters]

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