On Sun, Jan 16, 2022 at 06:10:58PM -0800, Christopher Barker wrote:
> In a way, what this might do is open the door to interning (some) frozen
> sets, like cPython does for some ints and strings.
I don't think that interning is relevant here. Interning is orthogonal
to the existence of a frozenset display. You don't need to use a literal
or display syntax to take advantage of interning:
# At least some versions of CPython
>>> m = int('78')
>>> n = int('78')
>>> m is n
True
And the existence of a literal or display syntax does not imply
interning, e.g. floats, tuples.
If there was a use for interning frozensets, we could do so regardless
of whether or not there is a display syntax.
> > (using f{...} as a frozenset literal) does something different - it
> > returns the *same* object, compiled once at function definition time,
> > every time it's called.
> >
>
> why/how would it do that? It *could* do that -- as above, with interning.
Inside a function, CPython can cache literals and immutable displays
made from purely literals, e.g. the tuple (1, 2, 3) but not the tuple
(1, 2, x)) in co_consts.
But we can't do any of that if the only way to create a frozenset is to
lookup the name "frozenset" and call that function. So while not all
frozensets inside a function could be built at compile-time and
retrieved from co_consts, some of them could -- if only we had a display
syntax equivalent to tuple displays.
Ironically, if the compiler can prove that a regular mutable set display
is only ever used once inside a function, CPython will make it a
frozenset:
>>> def func(a):
... return a in {1, 2, 4}
...
>>> func.__code__.co_consts
(None, frozenset({1, 2, 4}))
So ironically the only way to put a constant frozenset into co_consts is
to write it as a mutable set and only use it once!
> We don't make changes to Python syntax unless there is a compelling reason.
"Compelling" depends on the cost of making the change. The bigger the
cost, the more compelling the reason. The smaller the change, then the
reason need not be as huge.
I think this is a small change with a moderate benefit, which puts the
cost vs benefit ratio on the benefit side.
> There are any number of python types with no "literal" (well, not any
> number, it's quite defined. but still) heck, we don't even have literals
> for Decimal. Why this one?
Nearly all of those types are not builtins. As far as I can see,
frozenset is the only commonly used, immutable, builtin type that
doesn't have a literal display syntax, and the consequence of that is
that code using frozensets does much more work than needed.
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/DLD52KXWR7HYLYTXOTIFCCJIULZJ2P7L/
Code of Conduct: http://python.org/psf/codeofconduct/
