Ok, good. (open mouth, insert foot... :-)
But what I'd still like to know is this: what's the lifetime/scope of
string objects, or equivalently, where do they live?
As amrit@xvt.com pointed out already, you can use 'is' to compare
strings quickly, in some contexts. But if strings come and go with
a scope, this can't be used reliably: you can't be sure a string
you input or create in one scope will map to the same string
object when input/created in the future, in a different scope.
It would seem that the 'is' test would work, if strings are mapped
globally, and only go away when no longer referenced (if there's no
more references, 'is' makes no sense anyhow). But if strings are
mapped (hashed, whatever) and/or stored locally in a scope, or if they
are not mapped at all (each creation of a string "xyz" makes a new
string object), then you are out-of-luck with 'is', unless you can
determine all your symbols statically (not usually possible).
This may seem an esoteric issue, but it does come up in practice. In a
symbol manipulation program, it would be very handy to assume that all
strings map to the same object always, for the entire course of the
program run. If so, you can essentially use python strings like Lisp
'atoms' (which means alot to AI folks). If not, you need to manually
manage a symbol table (which isn't too bad, given python's dictionaries,
but is still extra work).
For example, given:
x = 'abc'
y = x
z = 'abc'
x is z <<-- fails?
of course x and y 'share' the same object, but do 'x' and 'z' refer to
the same object internally (will 'x is z' work)? If not, 'is' is mostly
useless for symbol comparison. (Again, I don't have access to Python to
test this at the moment.)
Similarly,
def b():
return 'abc' <<-- make/read a string in a different scope
def a():
x = 'abc'
y = b()
x is y <<-- fails?
Am I being just too "Lisp-headed" here?
Mark L.