>  but I don't think we should underestimate the cost of even this small complexity increase in the language. 

Actually, I think _maybe_ in this case the "complexity increase" cost is _negative_. People might waste
more time looking for a way of spelling a frozenset literal than just filling in "frozenset(....)". 
I for one, even knowing that the cost of writing "frozenset({1,2,3})" is negligible, would 
"feel" better there was a way to spell that without the needless conversions.

That said, an appropriate prefix for the {} just as we do for strigns would be nice, and
I disagree that it would be a significant source for "bugs". The "@{" is a nice
way out if people think "f{}" would be too close to "f()". And "<1,2,3>" just for frozensets
are indeed overkill. We already do "literal prefixing" with `"` after all. and formally extending this
prefix usage as needed for other literals seems like a nice path. 
But, as far as bikeshedding go, we also have "literal sufixing" (2.0j anyone?)- maybe
"{1,2,3}f" ? 

On Mon, Jan 17, 2022 at 2:43 PM Christopher Barker <pythonchb@gmail.com> wrote:
On Mon, Jan 17, 2022 at 9:07 AM Ronald Oussoren <ronaldoussoren@mac.com> wrote:

For example:

If flag in {‘the’, ‘allowable’, ‘flags’}:
    …

If a frozen set was even a little bit faster or used less memory, it would be nice to be able to create one directly.

Not really relevant for the discussion, but CPython automaticly creates a frozenset here (set display with immutable members) as an optimisation.

I think it's quite relevant to the discussion, because as far as I can tell, better performance in particular cases is the primary motivator.

Funny that this has come up -- not too long ago, I did some experiments with code like the above: and to the surprise of myself and some other long-time Pythonistas I work with, using sets, rather tha tuples in those kinds of constructs, e.g.:

if something in <a small collection or literals>:

was always as faster or faster with sets than tuples. That was surprising because we assumed that construction of a set would be slower than construction of a tuple. And that was probably the case ten years ago. The proof is in the pudding,so I never bothered to figure out why, but now I know :-)

Back to the topic at hand -- IIUC, set constants are already optimized, so the only places having a frozenset display would be when it is a constant, and it has to be a frozenset, where a regular one won't do. 

And that would only be noticeable  if it was in a function that didn't do much else, and was called often. And in that case, it could be put in the global scope to ameliorate some of that cost.

I believe Stephens' point is that the benefit may be fairly small, but so is the cost. I'm not so sure. I kind of like the idea myself, and the cost does seem small, but I don't think we should underestimate the cost of even this small complexity increase in the language. Sure, folks don't  have toeven  know it exists to write fine code, but it would be one more thing that newbies will need to figure out when they see it in others' code.

In fact, there' a lot of what I might call "Python Scripters" that aren't even familiar with the set display at all.

-CHB


--
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Q2VUUY6I4JJHQOHMO2JMMRPZGVZU44N6/
Code of Conduct: http://python.org/psf/codeofconduct/