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#...) and not as a "Letterlike Symbol" like ℝ or ℕ ( https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#... ). 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
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 -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TUCSR7... 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/