On Wed, Jul 11, 2018 at 4:45 PM Jelle Zijlstra <jelle.zijls...@gmail.com> wrote:
> 2018-07-11 16:25 GMT-07:00 Gregory P. Smith <g...@krypto.org>: > >> 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. >> >> 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). > > Whether implementing that is a good use of anyone's time is a different > question. > Neat optimization. I hadn't considered that. We do know for sure it is a builtin type at that point. If that were implemented, bytes objects could gain a to_bytearray() (along the lines of the int.to_bytes() API) method that could be optimized away in literal circumstances. -gps > >> 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 >> 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/