>  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 <python...@gmail.com>
wrote:

> On Mon, Jan 17, 2022 at 9:07 AM Ronald Oussoren <ronaldousso...@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-le...@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/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/VB4OI47LQ4PMNG6IQRFIQ2BR2LZII5L3/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to