<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 12:42 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">There's no way adding something like this today will suddenly change everything else that is part of having "symbols"; the proposed feature would be lacking the integration with the internals that makes it work well in some other languages.</blockquote></div><br>Wouldn't it be possible to simply have</div><div class="gmail_extra"><br></div><div class="gmail_extra">def Symbol(str):</div><div class="gmail_extra">    def __new__(cls_, *args):</div><div class="gmail_extra">        istr = sys.intern(str(*args))</div><div class="gmail_extra">        return str.__new__(cls, istr)</div><div class="gmail_extra"><br></div><div class="gmail_extra">and have sys.intern() return Symbol instances at some point?  I don't see any obvious compatibility problems.</div><div class="gmail_extra"><br></div><div class="gmail_extra">How would this be different from adding bool as a subclass of int some time ago?</div><div class="gmail_extra"><br></div><div class="gmail_extra">BTW, I think Pandas found [1] the way to have memory-saving string vectors without having a symbol type in the core.</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="http://pandas-docs.github.io/pandas-docs-travis/categorical.html">http://pandas-docs.github.io/pandas-docs-travis/categorical.html</a></div></div>