Why is Python’s intern built-in only for strings? It should be possible to extend intern to classes that are hashable and comparable, right?
Why is Python’s intern built-in only for strings? It should be possible to extend
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Why is Python’s intern built-in only for strings? It should be possible to extend intern to classes that are hashable and comparable, right?
The purpose of interning things is to be able to compare them by comparing their memory address; you ensure that you never create two objects with the same value (when the program requests the creation of a second object with the same value as an existing object, it instead receives a reference to the pre-existing object). This requires that the things you’re interning be immutable; if the value of an interned object could change, comparing them by address isn’t going to work.
In Python, it’s not possible to enforce the immutability of user-defined class instances, so it wouldn’t be safe to intern them. I suspect that’s the main theoretical reason intern doesn’t cover class instances.
Other built in immutable types are either comparable in a single machine-level operation already (int, float, etc), or immutable containers that can contain mutable values (tuple, frozenset). There’s no need to intern the former, and the latter can’t be safely interned either.