<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-07-11 16:25 GMT-07:00 Gregory P. Smith <span dir="ltr"><<a href="mailto:greg@krypto.org" target="_blank">greg@krypto.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Completely obvious what it does, but it irritates my aesthetic sensibilities every time I see:<div>  frozenset({spam, eggs})<div><br></div><div>Why? Because I assume under the hood that creates a set of spam and eggs before calling frozenset to copy it into a new frozenset object before the original set is garbage collected.  Wasteful.  This is in fact what happens in CPython 3.7 today.</div><div><br></div><div>I'd love to avoid this.  I have no rational measured reason to believe it even matters (thus seeding this on python-ideas and not elsewhere), even though it would technically speed up frozenset creation.</div><div><br></div><div>(a) detecting frozenset({}) as syntax to encode a frozenset in the python bytecode would be somewhat magical.  it could break the person unfortunate enough to monkeypatch out the frozenset builtin (really? don't do that!).</div><div><br></div><div>(b) abusing the concept of letter prefixes as we already have for strings on {} syntax would be possible but not at all obvious to a reader:</div><div><br></div><div>  f{} or c{} or r{} perhaps.  but then someone would want a frozendict.</div><div><br></div><div>(c) adding a .freeze() method to sets which would raise an exception if the set's refcount were > 1 and would mutate the type of the set object into a frozenset object in place.  refcount assertions are bad, not all VMs need refcounts.  The concept of a method that can mutate the type of the underlying object in place is... unpythonic.  even though technically possible to implement within CPython.</div><div><br></div></div></div></blockquote><div>This could be done safely and without too much craziness if .freeze() on a set returned a new frozenset. The compiler could then safely optimize {a, set, literal}.freeze() into a frozenset literal, because methods on builtin types cannot be monkeypatched. There's been talk of a similar optimization on calls to .format() on string literals (not sure whether it's been implemented).</div><div><br></div><div>Whether implementing that is a good use of anyone's time is a different question.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div></div><div>I'm -1 on all of my ideas above.  But figured I'd toss them out there as food for thought for the concept.</div><div><br></div><div>We lived for years without even having a set literal in the first place. So this isn't a big deal.</div><div><br></div><div>frozenset is not the only base type that lacks a literals leading to loading values into these types involving creation of an intermediate throwaway object: bytearray.  bytearray(b'short lived bytes object')</div><div><br></div><div>I was going to suggest complex was in this boat as well, but upon investigation we appear to do constant folding (or amazing parsingon that so 0.3+0.6j does turn into a single LOAD_CONST instead of two consts and an addition.  Nice!  Not that I expect practical code to use complex numbers.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-gps</div></font></span></div></div>
<br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
<br></blockquote></div><br></div></div>