The topic of introducing a set literal has been discussed numerous times before. While it is clear that using {} for sets and turning the literal for dicts into {:} is a change so breaking, you can’t take it serious, I think the suggestion of making {,} the empty set literal seems very valid and achievable.
Are there any problems or concerns with implementing the set literal?
Edit: I removed the references to the empty tuple literal (,). I actually didn’t remember that literal existing already and couldn’t test it at the time of writing my post.
This is a big enough change to warrant a PEP, so start by reading those and trying to find a core dev who’s willing to sponsor it. Keep in mind that status quo wins a stalemate, so you need to show why it’s sufficiently worthwhile to justify the change. This also means demonstrating that it’s worth using dedicated syntax rather than {*()} (which could be invisibly optimized).
For the record, I dispute that there’s any strong “current community consensus” for {/} - people stopped talking about it, but that doesn’t mean that there’s strong consensus. Put forward a proposal for the syntax that YOU believe is best for Python, and find a core dev who agrees; you aren’t beholden to that thread.
With the caveat that “try to find a core dev” doesn’t mean pestering anyone. They can already see these discussions and jump in if they are interested and have the time to sponsor a PEP. The fact that the previous discussion died off is a hint that perhaps none of them were that interested in this change.
Yes. “Find” definitely does not mean cold-calling all the core devs, begging them to sponsor your PEP. In general, the way to find a sponsor is to find someone who has already expressed interest. I’ve been trying to keep my tone positive here, but it is quite notable that across both this thread and the one linked to, only two core devs posted, once each, and not expressing any sort of support for the proposal. And the last two posts in the previous thread were both saying “you need a sponsor”, with nobody stepping forward.
So while I do want to stay positive and productive, the brutally honest truth is that this proposal has no chance of flying at the moment. Something will have to change before this can go forward. That’s why I said to read those documents, and did not recommend that you start writing a PEP.
Note however that because of the well known issues with Ideas category it is hard to tell if and how many core devs have seen these discussion. Not sure what the solution to this might be.
I’m sympathetic to the idea, and would probably be willing to co-author a PEP for empty-set-literal syntax, but I haven’t yet seen much consensus on a particular syntax: indeed, this thread suggests yet another. I would also caveat this with I’m not sure how much chance of success such a PEP would have, the idea goes back a long way without much concrete development.
Perhaps if people realise that the vast majority of ideas go nowhere, there will be fewer “please solve my immediate problem by fundamentally changing the language” threads?
Realistically, no, there’s no solution. The problem is that people ARE going to post a lot of unworkable ideas, and the core devs are quite right to not waste their time on them.
It just means that there needs to be something adopted for the canonical idiom for an empty set. I’ve always felt that set was the black sheep of the iterables family in part because of this difference. And I use sets a lot in what I do.
The question I’d have on {,} is the (lack of) generalisation to other container literals/expressions. [,] and (,) will stay invalid. {/} on the other hand requires knowing the symbol for the empty set, and many of our users don’t have a mathematical background. Hence I’ve voted for none of the options as there isn’t yet a clear winner for me.
The reason I advocate for {,} (for the third thread now) is that it is generalizable beyond only a set literal. Python adopted trailing commas, and this is essentially a trailing comma for an empty collection. The grammar of all collections could allow for this, [,] might look weird, but I don’t think it will confuse anyone, and (,) makes even more sense to me than () or (1,) as explicitly making a tuple.
Yes, IMO a PEP for {,} looses some of its strength if it doesn’t also include changes to allow [,] and (,). When I proposed , it came from me changing the grammar to first get (,) because I never like the special-case that () is the one time that parentheses DO make the tuple, but that one special case tends to lead learners to believe that parentheses always make the tuple.