Skip to content

PEP 802: Add Reference Implementation, expand Rejected Ideas #4537

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 8, 2025
Merged

PEP 802: Add Reference Implementation, expand Rejected Ideas #4537

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 65 additions & 6 deletions peps/pep-0802.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,8 +41,10 @@ of core concepts to beginners.
For example, users must be careful not to use ``set`` as a local variable name,
as doing so prevents constructing new sets.
This can be frustrating as beginners may not know how to recover the
:py:class:`set` type if they have overriden the name:
techniques to do so (e.g. ``type({1}-{1})``) are not immediately obvious.
:py:class:`set` 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 familiar
with the :py:class:`python:type` function.

Finally, this may be helpful for users who do not speak English,
as it provides a culture-free notation for a common data structure
Expand Down Expand Up @@ -79,6 +81,8 @@ with various proposals, including:
(`Discourse, August 2025 (#37)`_)
#. ``{-}``
(`python-ideas, August 2020`_)
#. ``(/)``
(`Discourse, March 2023 (#20)`_)
#. ``{,}``
(`Discourse, August 2025`_)
#. ``{/}``
Expand Down Expand Up @@ -106,6 +110,10 @@ The grammar for set displays will become:
.. productionlist:: python-grammar
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 forms
of the empty tuple and list respectively.

``{/}`` will become the default syntax for the empty set.

.. code-block:: python
Expand Down Expand Up @@ -141,6 +149,12 @@ There will be no other backwards incompatibile changes,
all current constructors for the empty set will continue to work,
and the behaviour of the :py:class:`set` type will remain unchanged.

Due to this, current code that uses ``set()`` will continue to work,
and can remain unchanged.
Developers of automated tools such as linters and formatters should avoid
encouraging 'churn' in existing projects by suggesting changes en-masse from
``set()`` to ``{/}``, unless explicitly requested by the user of such tools.


Security Implications
=====================
Expand Down Expand Up @@ -172,7 +186,9 @@ especially those that have a maths or science background.
Reference Implementation
========================

Forthcoming.
A reference implementation of this PEP exists as a pull request
in the CPython repository on Github:
`python/cpython#137565 <https://github.com/python/cpython/pull/137565>`__.


Rejected Ideas
Expand Down Expand Up @@ -217,8 +233,23 @@ Use the ``{*()}`` syntax
------------------------

This 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`), but is unwieldy
and complicated to explain; it was not designed for this purpose.
This has the benefit of support since Python 3.5 (:pep:`448`).

Explaining this notation requires understanding sequence unpacking, the empty
tuple, 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 users
will 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 of :pep:`448`, rather than an intentional attempt
to design a syntax that is easy to teach, understand, and explain.

Use the ``{-}`` syntax
----------------------
Expand All @@ -227,6 +258,20 @@ This syntax was originally proposed in :pep:`218`,
but removed from the PEP before it was accepted.
The authors prefer ``{/}`` due to the resemblance to :math:`\emptyset`.

Use the ``(/)`` syntax
----------------------

This notation has been suggested as a better visual resemlence of
the 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 brackets
are better than this proposal, as they are more consistent with the
current (since Python 3.0) set notation.

The authors prefer ``{/}`` because it combines the benefits of
visual resemblance to the mathematical symbol and to the existing set syntax,
unlike ``(/)``.

Use the ``{,}`` syntax
----------------------

Expand All @@ -240,6 +285,19 @@ Having a visibly different form, in ``{/}``, helps to reinforce the idea
that the syntax for the empty set is a special case, rather than a general rule
for all empty collections.

Create and use a new token for ``'{/}'``
----------------------------------------

There have been `previous proposals <https://discuss.python.org/t/73235/66>`__
to 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.


Open Issues
===========
Expand All @@ -258,10 +316,11 @@ Acknowledgements
Footnotes
=========

.. _Discourse, August 2025 (#37): https://discuss.python.org/t/101197/37
.. _Discourse, August 2025: https://discuss.python.org/t/101197
.. _Discourse, August 2025 (#37): https://discuss.python.org/t/101197/37
.. _Discourse, December 2024: https://discuss.python.org/t/73235
.. _Discourse, March 2023: https://discuss.python.org/t/25213
.. _Discourse, March 2023 (#20): https://discuss.python.org/t/25213/20
.. _explicitly deferred: https://mail.python.org/pipermail/python-3000/2006-May/001599.html
.. _python-3000, April 2006: https://mail.python.org/pipermail/python-3000/2006-April/001286.html
.. _python-3000, May 2006: https://mail.python.org/pipermail/python-3000/2006-May/001666.html
Expand Down