On Sun, Mar 2, 2014 at 4:07 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Sat, 01 Mar 2014 22:59:52 +1100, Chris Angelico wrote: >> And, as proven here in this thread, you do not know what you are doing. > > Steady on, that's a bit harsh. In context, I think that Marko is assuming > that the caller will only ever use the state values via their symbolic > names, e.g. only refer to them as IDLE, CONNECTED etc. and never use > their internal string values "IDLE", "CONNECTED".
A bit harsh, perhaps, but I stand by it: by repeatedly declaring that something is safe when it has been proven not safe, he shows that he does not know what he is doing - that he is not fully comprehending the significance of object value vs identity as regards strings. Incidentally, Python somewhat creates this issue, by sometimes interning and sometimes not. (And the same with small integers, although I've never heard the expression "int interning".) If strings were always interned, then it would be obvious that identity and value were one and the same. On the flip side, if a string literal always created a new string (that is, if it were more like a "string construction syntax" like square brackets for lists), then it would be obvious that each one is a separate object. I don't say either option is worth doing (especially the latter, O!), but by sometimes merging and sometimes not, Python does slightly blur the line between identity and value. (Obviously if strings were mutable, they'd *have* to have separate identities.) > I don't think that's a safe assumption, since it requires the caller to > only ever do the right thing, but if it is true, then using "is" in the > way he suggests cannot fail. If you're depending on the caller doing the right thing, it's still safe to use == rather than is. The only reason to use 'is' is to prevent the caller from stuffing in some other string that happens to be correct - hence his point about being able to change the keywords. If the caller stuffs in the string "INIT" instead of the object Foo.INIT, then "==" will happen to work until such time as Foo.INIT becomes "INITIALIZING", at which point it breaks. Preventing that means that unique object identity is crucial to the system working, and that's pretty much impossible with strings. (I don't say it's absolutely impossible; maybe if you intern some other string with the same value, and then construct the string you want out of pieces, and somehow prevent the compiler from figuring out what you're doing and optimizing it all away, then maybe you could have something that doesn't get reused anywhere else. But it's certainly not normal to be able to be sure of that.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
