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 <jsbu...@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-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/T7X3XI3ZQMQIQEMGPSTGLAFOCMXKWWFV/
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/VRGSQR7ISWFLKJTFDYWRNBGA47ECFDRU/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to