We propose a new notation,{/}, to construct and represent the empty set.This is modelled after the corresponding mathematical symbol ‘∅’.
This complements the existing notation for empty tuples, lists, anddictionaries, which use(),[], and{} respectively.
Sets are currently the only built-in collection type that have adisplay syntax,but no notation to express an empty collection.ThePython Language Reference notes this, stating:
An empty set cannot be constructed with{};this literal constructs an empty dictionary.
This can be confusing for beginners, especially those coming to the languagefrom a scientific or mathematical background, where sets may be in more commonuse than dictionaries or maps.
A syntax notation for the empty set has the important benefit of not requiringa name lookup (unlikeset()).{/} will always have a consistent meaning, improving teachabilityof core concepts to beginners.For example, users must be careful not to useset as a local variable name,as doing so prevents constructing new sets.This can be frustrating as beginners may not know how to recover theset type if they have overriden the name.Techniques to do so (e.g.type({1})) are not immediately obvious,especially to those learning the language, who may not yet be familiarwith thetype function.
Finally, this may be helpful for users who do not speak English,as it provides a culture-free notation for a common data structurethat is built into the language.
Sets were introduced to Python 2.2 viaPEP 218, which did not includeset notation, but discussed the idea of{-} for the empty set:
The PEP originally proposed{1,2,3}as the set notation and{-}forthe empty set. Experience with Python 2.3’ssets.pyshowed thatthe notation was not necessary. Also, there was some risk of makingdictionaries less instantly recognizable.
Python 3.0 introduced set literals (PEP 3100), but again chose not tointroduce notation for the empty set, which was omitted out of pragmatism(python-3000, April 2006,python-3000, May 2006).
Since then, the topic has been discussed several times,with various proposals, including:
{} to mean an empty set and using{:} for an empty dictionary(python-ideas, January 2008,Discourse, March 2023)∅ orϕ)(python-ideas, April 2021)<>(python-ideas, November 2010,Discourse, December 2024)s{}(python-ideas, June 2009){*()}, perhaps optimising to compile this to theBUILD_SET opcode(Discourse, August 2025 (#37)){-}(python-ideas, August 2020)(/)(Discourse, March 2023 (#20)){,}(Discourse, August 2025){/}(python-ideas, January 2008)set() (i.e. doing nothing)The authors propose{/} as the notation,being in their opinion the best of these options.It is simple and concise, with the benefit of resembling the mathematicalnotation for the empty set,∅.This makes it an easier mnemonic to explain than several in the language,such as** for exponentiation or@ for matrix multiplication.
The{/} notation was also the most popular in arecent Discourse poll,selected by 41% of respondents overall and 60% of those voting for a new syntax.
Brief summaries for the other proposals may be found inRejected Ideas.
The grammar for set displays will become:
set_display ::= "{" ("/" | flexible_expression_list | comprehension) "}"The parser will emit a specialised error message for(/) and[/],indicating that these are invalid syntax, and suggesting the correct formsof the empty tuple and list respectively.
{/} will become the default syntax for the empty set.
>>>type({/})<class 'set'>>>>{/}==set()True
The representation and string forms of the empty set will change to'{/}'.
>>>repr({/})'{/}'>>>repr(set())'{/}'>>>str({/})'{/}'>>>str(set())'{/}'
There will be no behavioural changes toset objects.
Code that relies on therepr() orstr() of the empty setwill no longer work, because the representation will change.
There will be no other backwards incompatibile changes,all current constructors for the empty set will continue to work,and the behaviour of theset type will remain unchanged.
Due to this, current code that usesset() will continue to work,and can remain unchanged.Developers of automated tools such as linters and formatters should avoidencouraging ‘churn’ in existing projects by suggesting changes en-masse fromset() to{/}, unless explicitly requested by the user of such tools.
None.
All users can be taught that{/} is the new spelling forset(),and that it is equivalent in all other ways.To help reinforce this, we will update the documentation to use{/}instead ofset(), including the tutorial, standard libary modules,and the Python Language Reference.
For new users, sets can be introduced through syntax, noting that the fourbuilt-in collection types with syntax all have empty forms:(),[],{/}, and{}.
The empty set uses a forwards slash to differentiate it froman empty dictionary.It uses this syntax because it looks like the mathematical symbolfor the empty set (’∅’).This can be used as a helpful mnemonic when teaching beginners,especially those that have a maths or science background.
A reference implementation of this PEP exists as a pull requestin the CPython repository on Github:python/cpython#137565.
{} to mean an empty set and use{:} for an empty dictionaryThis would be an entirely backwards incompatible change,all current emptydict objects would become sets.
∅ orϕ)The Unicode character ‘U+2205 ∅ EMPTY SET’ is not currently a valid identifier.Introducing a Unicode character as syntax would be hard to use,as it does not appear on standard keyboards.
Using other characters that look like ∅, such as ‘U+03C6 ϕ GREEK SMALL LETTERPHI’ or ‘U+00D8 Ø LATIN CAPITAL LETTER O WITH STROKE’, would be more confusingwith the same drawbacks of using a Unicode character.
<> syntaxIt does not have a resemblance to the syntax for non-empty sets.This would be harder to explain than this PEP’s proposal.
This syntax further has historic use as the inequality operator,which can still be accessed viafrom__future__importbarry_as_FLUFL.Using both thebarry_as_FLUFL future import and<> for the empty setwould lead to parser ambiguity: what would<><><> mean?
s{} syntaxThis syntax may cause confusion withs as a local variable.The only current use of prefixes of this kind is for string literals.This would be harder to explain than this PEP’s proposal.
{*()} syntaxThis relies on unpacking the empty tuple into a set, creating an empty set.This has the benefit of support since Python 3.5 (PEP 448).
Explaining this notation requires understanding sequence unpacking, the emptytuple, set literal syntax, and the concept of unpacking an empty sequence,producing no values to unpack.
This is an unwieldy syntax; not one that can be easily taught to beginners.We should avoid introducing complex notation with the proviso that userswill understand it later, or that it can be looked up online.This removes agency from the learner.Especially when using a programming language that can execute arbitrary code,it is important that users understand what the code they are writing does.
In the authors’ opinion, it would be a misttep to promote{*()}as the syntax for an empty set.It resulted as a side-effect ofPEP 448, rather than an intentional attemptto design a syntax that is easy to teach, understand, and explain.
{-} syntaxThis syntax was originally proposed inPEP 218,but removed from the PEP before it was accepted.The authors prefer{/} due to the resemblance to∅.
(/) syntaxThis notation has been suggested as a better visual resemlence ofthe empty set symbol (e.g. U+2205 ∅ EMPTY SET).However, it is a complete departure from the regular set syntax.To the authors, any of the proposed notations with curly bracketsare better than this proposal, as they are more consistent with thecurrent (since Python 3.0) set notation.
The authors prefer{/} because it combines the benefits ofvisual resemblance to the mathematical symbol and to the existing set syntax,unlike(/).
{,} syntaxThis is the authors’ next preferred option.However, if a single comma were to be used to represent an empty collection,it may be confusing why this could not be used for empty tuples or lists.In time, there might be proposals to add support for[,] and(,).This conflicts with the general principle that‘there should be one– and preferably only one –obvious way to do it’.Having a visibly different form, in{/}, helps to reinforce the ideathat the syntax for the empty set is a special case, rather than a general rulefor all empty collections.
'{/}'There have beenprevious proposalsto create a new token for this construct.This would require'{/}' to be written literally,with no whitespace between the characters.
We insted chose to allow whitespace between the brackets and the slash,treating{,/, and} as three distinct tokens,as we cannot see any reason to prevent it.However, we expect that the vast majority of uses will not include whitespace.
None.
This document is placed in the public domain or under theCC0-1.0-Universal license, whichever is more permissive.
Source:https://github.com/python/peps/blob/main/peps/pep-0802.rst
Last modified:2025-08-08 20:01:37 GMT