PEP 802: Display Syntax for the Empty Set

Zynyste · May 21, 2026, 9:29am

I believe the most prominent argument against any empty set literal proposed up to now may be summarized as follows:

No existing syntax allows for the natural deduction of {*} (or {/}or any other proposal) as the empty set literal, unlike [], {}, () which all follow naturally from non-empty container syntax

An inconsistent syntax adds overhead for people learning the language and for people trying to write elegant code, and should only be considered if it also adds some significant value that outweighs the cost. While the mere non-existence of an empty set literal is also a form of inconsistency, the people in favor of the status quo seemed to deem that the lesser sin.

h-vetinari · May 21, 2026, 9:42am

Please read the discussion above. The entire point about the appeal of {*} was that it can be made consistent across containers, and also consistent with unpacking.

tapetersen · May 21, 2026, 9:44am

Sidenote about font-ligatures, not a real proposal or argument.

Not as an argument against any proposal but rather as a thought for those that really want the empty set to stand out right now. (As in I’m well aware of a whole host of arguments why this doesn’t solve half of the problems people advocating real literals here wants to solve)

Getting a custom font-ligature transforming `set()` to a suitable glyph into one of the programmer fonts that have those might be an idea… (yeah remembering that you have to type something else does limit usability quite a bit but that’s somewhat inherent in the ligature hack anyway…)

pf_moore · May 21, 2026, 10:05am

Not true (IMO). The most prominent argument is simply that the benefits do not justify the costs.

The costs aren’t subjective. Having a set literal and set() as equally valid ways of writing an empty set causes confusion, increases risk of “style” arguments and junk PRs just changing from one to the other, and requires tutorials, courses and documentation to be modified. Making the new literal the officially preferred style requires changes to tutorials, documentation and courses, and adds pressure to maintainers of established projects to change to the new format in spite of the fact that doing so offers no actual benefit and causes backward compatibility issues. Making the set() form preferred reduces the benefits to almost nothing, and still adds confusion.

And the benefits? Some people get to use a literal form that they prefer over the current function call, and maybe there’s a potential for a performance benefit. That’s not a lot.

Not being able to get consensus on the syntax of the literal is, frankly, irrelevant. It seems to mostly just give people something to debate so that they don’t have to address the real issue (lack of meaningful benefits vs high costs).

Zynyste · May 21, 2026, 10:22am

Which is something that I have already acknowledged in a previous message and even may show support for, if it were to be discussed thoroughly.

My previous reply seems to have been interpreted as a rebuttal to your opinion; that was not my intention. I meant to clarify what the major argument against a new empty set literal was so that the discussion may stay on track.

That said, while I am in strong support of further discussing the two sets of syntax previously proposed, I wouldn’t necessarily say that the community has reached consensus on the usefulness of Null Literal Unpacking. This thread is 9 months long, and most of the discussion in here has been focused on other topics.

Zynyste · May 21, 2026, 10:35am

This… actually aligns with what I was trying to get across. My unstated assumption was that if there actually were some obvious natural choice for the empty set literal, more people would agree that implementing the obvious choice into the language would reduce existing overhead enough to justify the aforementioned costs. (I concede that this statement is also subjective)

pf_moore · May 21, 2026, 10:56am

Ah, OK. I still disagree, though. Even if everyone thought {*} was the perfect way to spell an empty set literal, the fact that huge amounts of existing code uses set() means that adding a new spelling at this point would be more disruptive than it’s worth.

If we were just implementing sets for the first time now, the situation would be different. But we’re not, and the big body of existing code changes things.

bwoodsend · May 21, 2026, 12:33pm

For me, trying to make {*} not an outlier by adding [*] and {**} is more confusing than just accepting that the / in {/} is a special case. I can see the rational if I think about it long enough but it doesn’t fit in my head at all.

gesslerpd · May 21, 2026, 1:05pm

I wrote that draft PEP about 1 year ago before this thread started because looked up history and discovered there was never strong enough reason to add empty set literal on it’s own.

So started trying to think of ways to add it indirectly while providing some other purpose and symmetry in the process.

The added benefit (*,) [*] {*} provides is there’s a way to write empty tuple without parentheses (x = *,) and avoiding pitfall of forgetting comma when adding first element. You can either swap out the “*” or keep adding to the tuple without thinking about if you need trailing comma or not (x = *, 1). So this feature removes some special case semantics of tuple rather than adding more special cases to language for set.

Limiting the syntax to the first element of the literal means this could also be viewed as disambiguated leading comma. Also, limiting it to only non-map literals means the only place it wouldn’t have a benefit is [] but can be avoided and only exists for symmetry.

I still think the empty set literal is useful for things like awkwardness in ast.literal_eval, repr of empty set is special case, avoiding builtin function call that can be shadowed/mocked, etc.

I will create an official PEP for this if any Python core developer would like to sponsor this direction.

Thanks @h-vetinari for reminding me of this!

jb2170 · May 21, 2026, 1:48pm

This looks a bit malbolge-y imo, like we’ve tried to do x, y = 1, 2 but we’re missing something . It reminds me of list (iterable?) unpacking like

>>> things = [5, 6, 7, 8]
>>> first, *rest = things
>>> first
5
>>> rest
[6, 7, 8]
>>>

but different

gesslerpd · May 21, 2026, 2:00pm

Haha, yeah I can see that, note this proposal only applies to right hand side contexts. Maybe best way to think about it is in a repl with *().

My proposal would work same way using that which works today, but shortened to “*” compiled out of the resulting AST and possibly limited to first literal element position.

But maybe the compiler should have a special case which compiles out the *() idiom starred node inside literal containers completely, then get all the benefits without meaningfully changing language (but doubt anyone would learn this if not official syntax).

Edit: Have put up a issue/PR that optimizes the {*()} idiom regardless of any decision on this PEP or other related proposals. Very early on @AA-Turner had mentioned this optimization.

github.com/python/cpython

Literal idiom for empty set `ast.unparse` symmetry

opened 10:27PM - 21 May 26 UTC

closed 10:38AM - 22 May 26 UTC

gesslerpd

type-feature interpreter-core pending

# 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](https://discuss.python.org/t/pep-802-display-syntax-for-the-empty-set/101676) 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-150205

github.com/python/cpython

gh-150204: Optimize literal null unpack idiom (#150205)

main ← gesslerpd:literal-null-unpack-idiom

opened 10:30PM - 21 May 26 UTC

gesslerpd

+108 -1

## Proposal When parsing a container literal whose only element is a direct `…*()`, simplify that element out of the AST during preprocessing. Proposed examples: ```python ast.parse('[*()]', mode='eval').body # List(elts=[]) ast.parse('{*()}', mode='eval').body # Set(elts=[]) ast.parse('(*(),)', mode='eval').body # Tuple(elts=[]) ``` The main motivation is full `ast.unparse()` symmetry for the empty-set idiom. 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. With this change: ```python empty_set = ast.Set(elts=[]) ast.parse(ast.unparse(empty_set), mode='eval').body ``` would produce the same `ast.Set(elts=[])` structure again. Applying the same rule to `[*()]` and `(*(),)` keeps the behavior consistent across the three container literal node types. ## Scope This proposal is intentionally narrow. Only simplify the direct lone `*()` case: - `[*()]` - `{*()}` - `(*(),)` - assignment forms such as `x = *(),` Do not simplify larger literals such as: - `[*(), 2]` - `{*(), 2}` - `(*(), 2)` - `[1, *(), 2]` - `{1, *(), 2}` - `(1, *(), 2)` - `[*(), *()]` That keeps the rule cheap, obvious, and tied to the empty-container idiom rather than introducing a broader AST rewrite. ## Why this belongs in AST preprocessing This behavior is better handled as AST canonicalization than as a special case in `ast.unparse()` tests or in `assertASTEqual()`. - It gives one canonical AST for a syntax that is operationally empty. - It fixes real round-tripping for `ast.unparse(ast.Set(elts=[]))`, not just one test helper. - It also benefits other AST consumers such as `compile(..., PyCF_ONLY_AST)`, `python -m ast`, and `ast.literal_eval()`. - It avoids teaching `assertASTEqual()` ad hoc equivalence rules for specific syntax patterns. In other words, the parser would produce the normalized tree once, and every downstream consumer would see the same result. ## Compatibility and behavior Runtime semantics do not change. The visible AST change is that tools would no longer see `Starred(Tuple([]))` for the lone forms above; they would instead see empty `List`, `Set`, or `Tuple` nodes. That is an externally visible AST change, but it is narrow and maps a degenerate form to the canonical empty container node. Notable consequences: - `ast.unparse(ast.parse('{*()}', mode='eval').body)` remains `{*()}` - `ast.unparse(ast.parse('[*()]', mode='eval').body)` becomes `[]` - `ast.unparse(ast.parse('(*(),)', mode='eval').body)` becomes `()` - `ast.literal_eval('{*()}')` can evaluate to `set()` once the parsed AST is canonicalized * Issue: gh-150204

gcewing · May 22, 2026, 12:17am

Crazy idea: