Even if f{1} creates a frozenset, I don't think f{} should create a
frozenset. I think it makes more sense to keep f{1: 2} open for frozendict
if it ever makes it in. Also, {} should be consisten with f{} (both should
create dicts). If you want an empty frozenset, you would have to do it the
same way you do it for sets: either frozenset() or f{*()}.
Best
Neil
On Tuesday, January 18, 2022 at 1:19:30 PM UTC-5 João Bernardo wrote:
>
> One thing to consider is if we're going to have a syntax capable of
> creating an empty frozenset, we need one that creates an empty set.
>
> if f{...} exists, then s{...} should also exist?
>
> Regards
> João Bernardo
>
>
> On Tue, Jan 18, 2022 at 2:59 PM Rob Cliffe via Python-ideas <
> python...@python.org> wrote:
>
>> I'm +1 on the idea.
>> I'm happy with the
>> f{ ... }
>> syntax (although I did suggest something else).
>> We already have letter-prefixes, let's stick to them rather than adding
>> something new (which conceivably might one day find another use).
>> Best wishes
>> Rob Cliffe
>>
>> On 18/01/2022 15:53, Ricky Teachey wrote:
>>
>> On Tue, Jan 18, 2022 at 10:02 AM Joao S. O. Bueno <jsb...@python.org.br>
>> wrote:
>>
>>> > 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" ?
>>>
>>
>> I have been following along with not much to comment but this response
>> sparked something in me.
>>
>> After reading all the viewpoints I think I would be +1 on the basic idea,
>> and a +1 on the postfix/suffix syntax just suggested... the other syntaxes
>> I'm more of +0.5
>>
>> I like the way the suffix FLOWS with the act of writing the program. When
>> I write a set, I am primarily focused on *what I am going to put in it*,
>> and whether or not it should be mutable is kind of a later thought/debate
>> in my head after I have established what it contains.
>>
>> As a dumb example, if my task at hand is "I need to create a bag of
>> sports balls", I am mostly thinking about what goes into that bag at first,
>> so I will write that first:
>>
>> >>> {Ball("basketball"), Ball("soccer"), Ball("football"),
>> Ball("golf")}
>>
>> Now I get to the end of that line, and I then sort of naturally think "ok
>> does it make sense to freeze this" after i know what is in it. With the
>> postfix syntax, I then either type the f:
>>
>> >>> {Ball("basketball"), Ball("soccer"), Ball("football"),
>> Ball("golf")}f
>>
>> ...or not. With a prefix type syntax, or a smooth bracket syntax, either:
>>
>> A. it takes slightly more "work' at this point to "convert" the set to a
>> frozenset, OR
>> B. i have to think about ahead of time-- before i have actually written
>> what is in the set- whether it will be frozen, or not.
>>
>> In contrast, when you are deciding whether to write a list vs a tuple,
>> you are deciding between two things that are fundamentally far more
>> different IDEAS than a "bag of things, frozen or unfrozen". A list is very
>> often more of an open ended stack than it is "an unfrozen tuple". A tuple
>> is very often much more of an object that can be used as a dictionary key,
>> or a member of a set, than it is a container of things (of course, it is a
>> container of things, too). These differences make is a lot easier to
>> choose, ahead of time, which one makes sense before you have even written
>> the line of code.
>>
>> Maybe I'm making too much of this, but I really like the idea of deciding
>> at the END of the set literal whether to tack on that "f".
>>
>> ---
>> Ricky.
>>
>> "I've never met a Kentucky man who wasn't either thinking about going
>> home or actually going home." - Happy Chandler
>>
>>
>>
>>
>> _______________________________________________
>> Python-ideas mailing list -- python...@python.org
>> To unsubscribe send an email to
>> python-id...@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python...@python.org/message/T7X3XI3ZQMQIQEMGPSTGLAFOCMXKWWFV/
>>
>> <https://mail.python.org/archives/list/python-ideas@python.org/message/T7X3XI3ZQMQIQEMGPSTGLAFOCMXKWWFV/>
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>> _______________________________________________
>> Python-ideas mailing list -- python...@python.org
>> To unsubscribe send an email to python-id...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>
> Message archived at
>> https://mail.python.org/archives/list/python...@python.org/message/VRGSQR7ISWFLKJTFDYWRNBGA47ECFDRU/
>>
>> <https://mail.python.org/archives/list/python-ideas@python.org/message/VRGSQR7ISWFLKJTFDYWRNBGA47ECFDRU/>
>
>
>> 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/UPMMIIJTJ2X4R5N3UEWNW7R2UMSXPIJ6/
Code of Conduct: http://python.org/psf/codeofconduct/
