On Sun, Jan 16, 2022 at 05:53:19PM -0800, Brendan Barnwell wrote:
f{1, 2, 3}
I don't like that syntax. In the first place, as others have noted, it treads too close to existing function-call and indexing syntax. In those syntaxes, `f` is a name, whereas here it is not a name but just a syntactic marker (as in f-strings).
I think the horse has well and truly bolted on that. We've had syntactic markers that look like names forever: r"" goes back to Python 1.x days. Given the proposed syntax `f{a, b, c}`, that would be a transformation of three arguments a, b and c to a frozenset. That makes it closer to a function call than r"abc", which is not a transformation at all. So if this looks like a function call, good, that's because semantically it is kind of like a function call.
In the second place, I don't like the idea of using prefixes to change the types of objects like this. As far as I know we only have one example of that, namely byte strings.
Okay, so we have a precedence where a prefix on the delimiter changes the type: b'' is a different type to ''. In Python 2, it was the other way around, it was u'' that returned a different type. I think that the use of a prefix has been a moderately good design, good enough to cautiously extend it beyond raw strings to unicode strings, f-strings, and byte-strings, and beyond that to other delimiters. But if you think that the difference between '' and b'' is a terrible design flaw that has caused all sorts of badness in Python 3, I'm all ears. Please explain, and persuade me.
I would prefer some sort of augmented bracket notation, like {:1, 2, 3:} or something along those lines.
You don't think that people will associate {:1, 2:} with badly-written dicts rather than sets? If not, is there some sort of mental association between frozensets and those colons inside the set syntax? -- Steve