@@ -41,8 +41,10 @@ of core concepts to beginners.
41
41
For example, users must be careful not to use ``set `` as a local variable name,
42
42
as doing so prevents constructing new sets.
43
43
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.
46
48
47
49
Finally, this may be helpful for users who do not speak English,
48
50
as it provides a culture-free notation for a common data structure
@@ -79,6 +81,8 @@ with various proposals, including:
79
81
(`Discourse, August 2025 (#37) `_)
80
82
#. ``{-} ``
81
83
(`python-ideas, August 2020 `_)
84
+ #. ``(/) ``
85
+ (`Discourse, March 2023 (#20) `_)
82
86
#. ``{,} ``
83
87
(`Discourse, August 2025 `_)
84
88
#. ``{/} ``
@@ -106,6 +110,10 @@ The grammar for set displays will become:
106
110
.. productionlist :: python-grammar
107
111
set_display: "{" ("/" | flexible_expression_list | comprehension) "}"
108
112
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
+
109
117
``{/} `` will become the default syntax for the empty set.
110
118
111
119
.. code-block :: python
@@ -141,6 +149,12 @@ There will be no other backwards incompatibile changes,
141
149
all current constructors for the empty set will continue to work,
142
150
and the behaviour of the :py:class: `set ` type will remain unchanged.
143
151
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
+
144
158
145
159
Security Implications
146
160
=====================
@@ -172,7 +186,9 @@ especially those that have a maths or science background.
172
186
Reference Implementation
173
187
========================
174
188
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 >`__.
176
192
177
193
178
194
Rejected Ideas
@@ -217,8 +233,23 @@ Use the ``{*()}`` syntax
217
233
------------------------
218
234
219
235
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.
222
253
223
254
Use the ``{-} `` syntax
224
255
----------------------
@@ -227,6 +258,20 @@ This syntax was originally proposed in :pep:`218`,
227
258
but removed from the PEP before it was accepted.
228
259
The authors prefer ``{/} `` due to the resemblance to :math: `\emptyset `.
229
260
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
+
230
275
Use the ``{,} `` syntax
231
276
----------------------
232
277
@@ -240,6 +285,19 @@ Having a visibly different form, in ``{/}``, helps to reinforce the idea
240
285
that the syntax for the empty set is a special case, rather than a general rule
241
286
for all empty collections.
242
287
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
+
243
301
244
302
Open Issues
245
303
===========
@@ -258,10 +316,11 @@ Acknowledgements
258
316
Footnotes
259
317
=========
260
318
261
- .. _Discourse, August 2025 (#37) : https://discuss.python.org/t/101197/37
262
319
.. _Discourse, August 2025 : https://discuss.python.org/t/101197
320
+ .. _Discourse, August 2025 (#37) : https://discuss.python.org/t/101197/37
263
321
.. _Discourse, December 2024 : https://discuss.python.org/t/73235
264
322
.. _Discourse, March 2023 : https://discuss.python.org/t/25213
323
+ .. _Discourse, March 2023 (#20) : https://discuss.python.org/t/25213/20
265
324
.. _explicitly deferred : https://mail.python.org/pipermail/python-3000/2006-May/001599.html
266
325
.. _python-3000, April 2006 : https://mail.python.org/pipermail/python-3000/2006-April/001286.html
267
326
.. _python-3000, May 2006 : https://mail.python.org/pipermail/python-3000/2006-May/001666.html
0 commit comments