I think the best alias for "empty set" would be the Unicode character
"Empty set" or U+2205, i.e. "∅".
Alas, it's not a valid identifier in Python:
>>> ∅ = set()
File "<stdin>", line 1
∅ = set()
^
SyntaxError: invalid character '∅' (U+2205)
It works with the similarly looking "ϕ" or 'GREEK PHI SYMBOL' (U+03D5)
>>> ϕ = set()
>>> ϕ.union({1,2})
{1, 2}
But it's less than ideal.
I think it's an error from the Unicode standard to list the empty set as a
"Mathematical Operator" (
https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#Mathematical_Operators_block)
and not as a
"Letterlike Symbol" like ℝ or ℕ (
https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#Letterlike_Symbols_block
).
Ex:
>>> ℕ = [0, ...] # Whatever that means...
>>> ℕ
[0, Ellipsis]
So yes, the language would need to be changed to allow the proper empty set
unicode symbol to be used.
S.
On Thu, Apr 8, 2021 at 11:27 PM <[email protected]> wrote:
> Hello,
>
> I would like to propose adding literal syntax to allow creation of an
> empty set without the need to call the type constructor. I believe the best
> choice for such a literal, and one that has been proposed before, is `{,}`.
>
> I know this idea has surfaced a few times before, but I cannot find any
> serious consideration since the 3K ideas chain with the closest to a
> pronouncement here
> https://mail.python.org/pipermail/python-3000/2006-May/001599.html. In
> that thread the idea of a new syntax for the empty set did not seem to be
> rejected outright, but more that the idea of set literals at all was still
> in question and as empty sets were not implemented for 2.7 they were
> ultimately still left out of 3k, intentionally or unintentionally.
>
> Within cpython itself `set()` is used just over 200 times to assign a
> variable the value of an empty set. As a comparison `dict()` is used only
> 15 times, and all but one of those are within the test module, mostly for
> testing dict. On the other hand, `{}` is used for assignment a little over
> 1300 times; I think there is a clear preference for using literal over type
> construction when possible.
>
> I have a working implementation of this new syntax at
> https://github.com/ucodery/cpython/tree/empty-set which includes a few
> changes. Python from this branch allows `{,} == set()` but also `[,] ==
> list()` and `(,) == tuple`. Partly this was because the grammar changes
> were easier to do all three but also because I personally liked keeping
> some symmetry between these collection literals. The main point of starting
> this thread is to gather opinions on adding `{,}` to the language, but I
> would like to discuss the other two as well.
>
> As a secondary point, I do think that this new tuple syntax would make
> teaching python easier. Those new to python often believe that parentheses
> are what make a tuple and only later, if ever, realize that it is only
> value(s) followed by a comma that construct a tuple and that parentheses
> are places around it mainly for readability. This misunderstanding often
> leads to a bug like `iter((4))`, assuming the programmer meant
> `iter((4,))`. I believe this confusion about whether it is the parentheses
> or the commas that construct a tuple is deepened because two parentheses
> surrounding nothing _does_ specifically create the empty tuple but `empty =
> ,` is a SyntaxError. With this literal tuple change, those new to the
> language can be told that parentheses containing at least one comma always
> creates a tuple (at least anywhere is is grammatically valid to have a
> tuple).
>
> Jeremy
> _______________________________________________
> Python-ideas mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/TUCSR7C5K7A4Z62564CTYRR2C6VNGEQ4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/X4TX2HDNKDJ7PVZL3DVI5QD2MIMRHKO4/
Code of Conduct: http://python.org/psf/codeofconduct/
