On Sat, 22 Jan 2022 at 00:30, Joao S. O. Bueno <jsbu...@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
_______________________________________________
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/X3KPFUAWSTO7QKROWW465P2CFX27NDUP/
Code of Conduct: http://python.org/psf/codeofconduct/
