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-ideas@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 <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 to > python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > 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-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/ >
_______________________________________________ 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/5D4QI6O2ZUYHO7PX25TJOSJHAMIPFRWK/ Code of Conduct: http://python.org/psf/codeofconduct/