Bernard Lim <[EMAIL PROTECTED]> writes: > <paraphrase> > Depending on implementation, for immutable types, operations that > compute new values may or may not actually return a reference to any > existing object with the same type and value, while for mutable > objects this is (strictly)? not allowed. > </paraphrase> > > Using the example given in 3.1, how do I verify that this is true > pertaining to immutable types?
You don't. By the language definition, it's entirely up to the implementation whether *and when* to do this. So, even if you find a particular session that does this, there's no telling whether it'll stop happening at some future session using *exactly the same inputs* -- and, if it did change, that would also be entirely within the definition of the language. If something in a language specification says "this set of conditions leads to undefined behaviour", or "this aspect is implementation defined", then *absolutely any behaviour* that fits the rest of the definition is allowed, even if that results in non-determinism from the programmer's perspective. In short: Don't ever rely on such behaviour labelled with these "may or may not" phrases, even if you run some tests and appear to get predictable results. -- \ “The power of accurate observation is frequently called | `\ cynicism by those who don't have it.” —George Bernard Shaw | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
