On Sat, 22 Jan 2022 at 00:30, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
Yes, but have you _seen_ the bickering about the existing bracket
choices just for frozenset? Eww. Hence the going for a distinct operator altogether. Yes, I'd prefer brackets of some kind too, but they're taken.
If one uses prefixes, you start from 53 valid (all latin areas, upper, lower and @) new brackets for {} .
Distinguishing upper and lower would be even more inconsistent, since strings don't. Or rather, they sorta-kinda do, but always define that x and X mean the same thing. The at sign is an operator, and cannot be used as a prefix. So you have 26, which is approximately 25 more than you will actually want, or maybe 23 if there's an explicit prefix for "set" and "dict" in there somewhere.
I can't see how they are "all taken" when the strongest argument against prefixing seems to be "but _only strings_ should have prefixes". (with the "typing f{} instead of f() is going to be a bug magnet" as a runner up). None of those stand up to any logical analysis
Nice how you are the judge of whether it stands up to logical analysis. Nice way to pooh-pooh an argument without any actual reasoning. Oh wait, that's exactly what logical analysis would be... So actually it's your rebuttal that doesn't stand logical analysis :)
It is ok voting that "the language should not be made more complex at this point, and we won't add any new syntax for a frozenset", but I think that if it is agreed that frozensets are ok, a prefix is just straightforward.
And then, adopting prefixes for curly braces, you have 52 other bracket types to try and sell this "generic freezer operator" you are presenting here. :-).
Prefixes on braces are not a generic freezer operator. An operator has to be able to act on any object, not a specific syntactic construct. Unless you're suggesting that q{obj} would mean "obj, but frozen", which would be a quite inconsistent protocol, given that it's doing the same job as a function call, looks disturbingly similar to a function call, but is actually an operator. I don't know of anything else in Python that behaves that way, except *maybe* the way a comma can create a tuple, or can be used as part of a series of things. (And that's a pretty weak line of argument, except in specific cases where it's actually ambiguous - see assert (x,y) for instance.) ChrisA