I completely get your pain, the Copy seems like a waste of ressource.
However I think making an optimisation on the C-Level is better than
introducing the litteral, because Python is a general purpose langauge and most
of the appplication don't need frozenset or bytearrays and that would clutter
the base elements one must know and introduce questions on beginners.
So yes, I'm +1 on your (a) solution if it is completely a C-Level optimisation.
Your (c) solution is an idea. Again, C-Level optimisation, because
usuability-wise, what's wrong with a copy of a hash table ?
The problem with the f{} syntax is that the letters come from nowhere,
frozenset{'hello', 'world'} would be a better syntax but it looks like "{} is a
slicing operator like frozenset[''hello', 'world'] would call
frozetset.__getitem__( ('hello', 'world') ).
Le jeu. 12 juil. 2018 à 01:26, Gregory P. Smith
<g...@krypto.org<mailto:g...@krypto.org>> a écrit :
Completely obvious what it does, but it irritates my aesthetic sensibilities
every time I see:
frozenset({spam, eggs})
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.
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.
(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!).
(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:
f{} or c{} or r{} perhaps. but then someone would want a frozendict.
(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.
I'm -1 on all of my ideas above. But figured I'd toss them out there as food
for thought for the concept.
We lived for years without even having a set literal in the first place. So
this isn't a big deal.
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')
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.
-gps
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org<mailto:Python-ideas@python.org>
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
