[Guido] >> Sorry, if you're usign *any* immutable value there and expecting it >> to be a unique object, you're cruisin' for a bruisin', so to speak. >> The language spec explicitly *allows* but does not *require* the >> implementation to cache and reuse immutable values. [Andrew] > Ay, there's the rub. > > Aren't you saying that using "is" to compare immutables is always > broken, unless you know that the immutable values are singletons? No, because it's still <wink> the purpose of "is" to expose the implementation. Examples of system-level uses were given earlier; for another, if I'm doing a crawl over gc.get_referrers(x) trying to account for all the references to the object currently bound to x (this is something I do often when trying to track suspected memory leaks), object identity is the only notion of equivalence that's relevant, and it doesn't matter whether that object is a singleton, or mutable, neither any other property of x's type or behavior -- the only thing about x that matters in this context is its indenty, and locating which other objects refer to exactly it. If I know that references to the string "<oid at 00000001>" are growing over time, I'll in fact add an "is" test against that string to the guts of Zope's test.py leak-detection scaffolding. It's necessary to be able to spell this in Python -- although it's not necessary (IMO) to be able to spell it with two letters.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4