Carl Johnson wrote:
Ron Adam wrote:
Ben Finney wrote:
Carl Johnson writes:
we could introduce an empty set-literal and an odict-literal, and add a more explicit form to replace the existing set literal. What do you mean by “more explicit”? The existing set literal syntax is quite explicit. I think Carl is thinking that it is more concise and easier to read.
Yes, that's part of it. Thank you. What I mean by "explicit" in this case is something like "harder to accidentally misparse in your mind." So for example if you see {f(i) for i in my_data} obviously it is unambiguously a set-comprehension, but if you aren't paying close enough attention you might mistakenly think it was a dict-comprehension. On the other hand, s{f(i) for i in my_data} more or less screams, "I am a set-comprehension!" On the other hand, it's ugly, and the BDFL doesn't like it. So, it's probably a dead idea now…
Terry Reedy wrote:
Literals represent constants. They are sensibly interpreted into constants sometime before runtime, even if at a later stage than I thought.
I'm not sure what you're getting at here. What about d = {} ? That's not immutable. Nor is l = [1, 2, 3]. Or by "constant" do you just mean something that will be the same at the *start* of every program, but it may or may not change before the program is over?
- - - -
I think ["a": 1, "b": 2] is an interesting syntax, and certainly more elegant than o{"a": 1, "b": 2} but I worry that it could be ambiguous. I can't think of any way to do it off the top of my head, but might there be some valid way of writing l[1:2] that could be ambiguous between the two? If nothing else, it would confuse newbies about what [:] means: slice or odict?
What about l[2]? Is [2] an index or a list?