[Python-ideas] anyone need a frozenset or bytearray literal?

[Jelle Zijlstra]

2018-07-11 16:25 GMT-07:00 Gregory P. Smith <greg at 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.


> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180711/a07f0be3/attachment-0001.html>