Skip to content

Commit 43fa042

Browse files
authored
PEP 802: Add Reference Implementation, expand Rejected Ideas (#4537)
1 parent aaa72ee commit 43fa042

File tree

1 file changed

+65
-6
lines changed

1 file changed

+65
-6
lines changed

peps/pep-0802.rst

Lines changed: 65 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -41,8 +41,10 @@ of core concepts to beginners.
4141
For example, users must be careful not to use ``set`` as a local variable name,
4242
as doing so prevents constructing new sets.
4343
This can be frustrating as beginners may not know how to recover the
44-
:py:class:`set` type if they have overriden the name:
45-
techniques to do so (e.g. ``type({1}-{1})``) are not immediately obvious.
44+
:py:class:`set` type if they have overriden the name.
45+
Techniques to do so (e.g. ``type({1})``) are not immediately obvious,
46+
especially to those learning the language, who may not yet be familiar
47+
with the :py:class:`python:type` function.
4648

4749
Finally, this may be helpful for users who do not speak English,
4850
as it provides a culture-free notation for a common data structure
@@ -79,6 +81,8 @@ with various proposals, including:
7981
(`Discourse, August 2025 (#37)`_)
8082
#. ``{-}``
8183
(`python-ideas, August 2020`_)
84+
#. ``(/)``
85+
(`Discourse, March 2023 (#20)`_)
8286
#. ``{,}``
8387
(`Discourse, August 2025`_)
8488
#. ``{/}``
@@ -106,6 +110,10 @@ The grammar for set displays will become:
106110
.. productionlist:: python-grammar
107111
set_display: "{" ("/" | flexible_expression_list | comprehension) "}"
108112

113+
The parser will emit a specialised error message for ``(/)`` and ``[/]``,
114+
indicating that these are invalid syntax, and suggesting the correct forms
115+
of the empty tuple and list respectively.
116+
109117
``{/}`` will become the default syntax for the empty set.
110118

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

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

145159
Security Implications
146160
=====================
@@ -172,7 +186,9 @@ especially those that have a maths or science background.
172186
Reference Implementation
173187
========================
174188

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

177193

178194
Rejected Ideas
@@ -217,8 +233,23 @@ Use the ``{*()}`` syntax
217233
------------------------
218234

219235
This relies on unpacking the empty tuple into a set, creating an empty set.
220-
This has the benefit of support since Python 3.5 (:pep:`448`), but is unwieldy
221-
and complicated to explain; it was not designed for this purpose.
236+
This has the benefit of support since Python 3.5 (:pep:`448`).
237+
238+
Explaining this notation requires understanding sequence unpacking, the empty
239+
tuple, set literal syntax, and the concept of unpacking an empty sequence,
240+
producing no values to unpack.
241+
242+
This is an unwieldy syntax; not one that can be easily taught to beginners.
243+
We should avoid introducing complex notation with the proviso that users
244+
will understand it later, or that it can be looked up online.
245+
This removes agency from the learner.
246+
Especially when using a programming language that can execute arbitrary code,
247+
it is important that users understand what the code they are writing does.
248+
249+
In the authors' opinion, it would be a misttep to promote ``{*()}``
250+
as the syntax for an empty set.
251+
It resulted as a side-effect of :pep:`448`, rather than an intentional attempt
252+
to design a syntax that is easy to teach, understand, and explain.
222253

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

261+
Use the ``(/)`` syntax
262+
----------------------
263+
264+
This notation has been suggested as a better visual resemlence of
265+
the empty set symbol (e.g. U+2205 ∅ EMPTY SET).
266+
However, it is a complete departure from the regular set syntax.
267+
To the authors, any of the proposed notations with curly brackets
268+
are better than this proposal, as they are more consistent with the
269+
current (since Python 3.0) set notation.
270+
271+
The authors prefer ``{/}`` because it combines the benefits of
272+
visual resemblance to the mathematical symbol and to the existing set syntax,
273+
unlike ``(/)``.
274+
230275
Use the ``{,}`` syntax
231276
----------------------
232277

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

288+
Create and use a new token for ``'{/}'``
289+
----------------------------------------
290+
291+
There have been `previous proposals <https://discuss.python.org/t/73235/66>`__
292+
to create a new token for this construct.
293+
This would require ``'{/}'`` to be written literally,
294+
with no whitespace between the characters.
295+
296+
We insted chose to allow whitespace between the brackets and the slash,
297+
treating ``{``, ``/``, and ``}`` as three distinct tokens,
298+
as we cannot see any reason to prevent it.
299+
However, we expect that the vast majority of uses will not include whitespace.
300+
243301

244302
Open Issues
245303
===========
@@ -258,10 +316,11 @@ Acknowledgements
258316
Footnotes
259317
=========
260318

261-
.. _Discourse, August 2025 (#37): https://discuss.python.org/t/101197/37
262319
.. _Discourse, August 2025: https://discuss.python.org/t/101197
320+
.. _Discourse, August 2025 (#37): https://discuss.python.org/t/101197/37
263321
.. _Discourse, December 2024: https://discuss.python.org/t/73235
264322
.. _Discourse, March 2023: https://discuss.python.org/t/25213
323+
.. _Discourse, March 2023 (#20): https://discuss.python.org/t/25213/20
265324
.. _explicitly deferred: https://mail.python.org/pipermail/python-3000/2006-May/001599.html
266325
.. _python-3000, April 2006: https://mail.python.org/pipermail/python-3000/2006-April/001286.html
267326
.. _python-3000, May 2006: https://mail.python.org/pipermail/python-3000/2006-May/001666.html

0 commit comments

Comments
 (0)