diff --git a/peps/pep-0802.rst b/peps/pep-0802.rst index c67a28bb892..49c7afa36a8 100644 --- a/peps/pep-0802.rst +++ b/peps/pep-0802.rst @@ -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 @@ -79,6 +81,8 @@ with various proposals, including: (`Discourse, August 2025 (#37)`_) #. ``{-}`` (`python-ideas, August 2020`_) +#. ``(/)`` + (`Discourse, March 2023 (#20)`_) #. ``{,}`` (`Discourse, August 2025`_) #. ``{/}`` @@ -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 @@ -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 ===================== @@ -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 `__. Rejected Ideas @@ -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 ---------------------- @@ -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 ---------------------- @@ -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 `__ +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 =========== @@ -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