Oren Tirosh wrote: > Why not make interned strings a type? <type 'istr'> could be an > un-subclassable subclass of string. intern would just be an > alias for this type. No two istr instances are equal unless they are > identical. I guess PyString_CheckExact would need to be changed to > accept either String or InternedString. The possibility of people starting to write code that depended on whether strings were 'string' or 'istr', and all the breakage and incompatibility that would result, seems much too ugly to contemplate. Pass an 'istr' into a routine that expects strings, and it would appear to be a string right up until someone tried to == it, whereupon all hell would break loose. The acid test for subtyping is substitutability: type 'istr' would not fulfill the contract of 'string', and neither would 'string' fulfill the contract of 'istr'. Therefore, if you really wanted to do this, your new type (let's call it 'symbol') would have to be completely independent from both strings *and* interned strings. There's no subclass relationship. -- ?!ng
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