Literal idiom for empty set `ast.unparse` symmetry

[gesslerpd]

Feature or enhancement

Proposal:

Today, ast.unparse(ast.Set(elts=[])) renders as {*()}, because Python has no dedicated empty-set literal. Without AST canonicalization on parse, reparsing that output produces a Set containing Starred(Tuple([])) instead of an empty Set, so the AST does not round-trip cleanly.

Regardless of decision on PEP 802 this may provide a win for anyone who has already adopted this {*()} idiom.

Has this already been discussed elsewhere?

I have already discussed this feature proposal on Discourse

Links to previous discussion of this feature:

Various contributors to the discussion on PEP 802: https://discuss.python.org/t/pep-802-display-syntax-for-the-empty-set/101676

• https://discuss.python.org/t/pep-802-display-syntax-for-the-empty-set/101676/7
• https://discuss.python.org/t/pep-802-display-syntax-for-the-empty-set/101676/231

Linked PRs

• gh-150204: Optimize literal null unpack idiom #150205
• gh-150204: Optimize bytecode for leading null unpack idioms in collection literals #150265

[picnixz]

AFAIR, we do not ensure round tripping.

[picnixz]

And I do not really see why we should collapse that. {*()} is legitimate and may be useful for refactoring tools but with your change they may not necessarily see it I guess?

[picnixz]

Also please tell me in the long discussion where exactly there was a consensus for this specific change in the AST unparser. Issues are for actionable changes, this one was not even discussed.

[gesslerpd]

And I do not really see why we should collapse that. {*()} is legitimate and may be useful for refactoring tools but with your change they may not necessarily see it I guess?

With this change, there's nothing to refactor it to it's already in the best form possible that ast.unparse would "recommend". If there ever is a more canonical way to represent the empty-set as result of PEP 802 or some other future PEP, this can be removed and it can be detected by refactoring tools.

Also please tell me in the long discussion where exactly there was a consensus for this specific change in the AST unparser. Issues are for actionable changes, this one was not even discussed.

Not sure there's consensus, although this was mentioned multiple times in the thread (including by the core dev sponsoring the PEP). Thought it was something actionable that could be done regardless of any full PEP decisions.

Note: I have since reduced the scope of linked PR to only set literal case, it won't show up unless that is ever reopened. Also left a comment there about performance cost impact, I think enough things use this idiom that it's worth a discussion.

[picnixz]

With this change, there's nothing to refactor it to it's already in the best form possible that ast.unparse would "recommend".

That's assuming your tool is using ast.unparse. If someone writes {*()} and you want to suggest "use set() instead", you'll need to match the literal text and not just its AST. Knowing that you have Set with Starred element means that you can suggest "set()" alternative, but if ast.parse() already tells you that it's Set(elts=[]), then you cannot distinguish it. But if your tool knows that it's Set(elts=[Starred(...)]), you then know that it'd be {*()} and then you can suggest using set().

I don't like that ast.parse would be produce Set(elts=[]) instead of the starred form. It is maybe equivalent at runtime (and even at AST transformation time) but it's not equivalent at parsing time. And if you're interested in only static analysis, you really might want to retain the starred information.

[gesslerpd]

Starting to feel like I misunderstood some of the comments on original discussion thread, this change seems more useful with potentially similar performance cost implemented as a bytecode optimization step.

Then avoids all these AST impacts: #150265

Associating with this issue as it's still related to the ast.unparse idiom {*()} and is the recommended way to "spell" empty set literal today without any set builtin function shadow/mock considerations.

[picnixz]

I honestly don't know WHY we should avoid spelling set(). What's wrong with this? just making {*()} faster for niche cases is not a reason for changing the optimizer, sorry.

[gesslerpd]

I honestly don't know WHY we should avoid spelling set(). What's wrong with this? just making {*()} faster for niche cases is not a reason for changing the optimizer, sorry.

Reason for this might boil down to the entire reason for PEP 802, this isn't going to give a good way to write empty set as a literal. Probably only for advanced users, can eliminate friction conversions when adding or removing the first element of a set literal in code.

It is a micro-optimization, but does provide some benefit to something that is already part of the language because ast.unparse says this the closest thing to empty-set literal representable in the current grammar. Things like ast.literal_eval could translate the already special case set() to this form (afterwards since it contains Starred node). Ultimately, set() is not a literal so it has all implications that come with that.