Hi Steve D'Aprano started this thread on 16 Jan, referencing https://bugs.python.org/issue46393. In the 95th message in this thread, on 27 Jan, Stephen J. Turnbull wrote: I think for many of us (specifically me, but I don't think I'm alone) it's
equally important that we aren't persuaded that there's a need for a frozenset literal great enough to overcome the normal reluctance to add syntax. A number of important cases are already optimized to frozensets, and use cases and (more important) benchmarks showing that this optimization is important enough to add syntax so the programmer can hand-code it are mostly to entirely lacking.
On 17 Jan, Serhiy Storchaka wrote to the b.p.o issue Steve D'Aprano referenced: As Steven have noted the compiler-time optimization is not applicable here
because name frozenset is resolved at run-time.
In these cases where a set of constants can be replaced with a frozenset of
constants (in "x in {1,2,3}" and in "for x in {1,2,3}") the compiler does it.
And I don't think there is an issue which is worth changing the language.
Creating a frozenset of constants is pretty rare, and it is even more rare in tight loops. The most common cases (which are pretty rare anyway) are already covered.
This is message 96 in this thread. Perhaps something bad (or good) will happen when we get to message 100. https://www.theregister.com/2022/01/27/linux_999_commits/ -- Jonathan