My suggestion is to change the syntax for creating an empty set and an empty dictionary as following. an_empty_set = {} an_empty_dictionary = {:} Compatibility issues could be resolved with a program which takes a Python program (codes) as a text and edits it. Sent from my iPhone
On Fri, Mar 30, 2018 at 2:42 AM, Julia Kim <julia.hiyeon.kim@gmail.com> wrote:
Unfortunately, that's not sufficient for backward compatibility. Imagine reading something on Stack Overflow that has this line of code in it: words = {} Does that make an empty set or an empty dict? How would anyone know? Are you going to go through every piece of code on Stack Overflow and change it? What about all the blogs out there? Printed books? Simply transforming code doesn't work. Having the same syntax perform drastically different things on different versions of the interpreter is almost certainly not going to fly. The only way that this might be usable is if you use a __future__ directive. And if it were done that way, I would expect most code out there to NOT use the directive, and therefore to keep today's semantics - which means the change effectively hasn't happened for most people. ChrisA
On Fri, Mar 30, 2018 at 3:00 AM, Stephan Houben <stephanh42@gmail.com> wrote:
Maybe, but that symbol generally means the unique immutable empty set in mathematics, so a closer equivalent would be frozenset(), in the same way that () gives you a singleton immutable empty tuple. But yes, I would like to some day have a literal for an empty set. Just not "{}". ChrisA
Mathematically, {1,2,3} is a unique, immutable set, too. {1,2,3} \union {4} doesn't modify {1,2,3}; it's just another way to represent another unique immutable set {1,2,3,4}. So I don't seen any problem (aside from the general resistance Unicode) with using ∅ to mean set(). However, just as string literals take a variety of prefixes (r, u, b, f), why can't set/dict literals? d{} == {} == dict() d{"a": 2} == {"a": 2} == dict(a=2) s{1,2,3} == {1,2,3} == set([1,2,3]) s{} == set() f{} == frozenset() f{1,2,3} == frozenset({1,2,3}) (I vaguely recall hearing a proposal to use o{...} for ordered dicts, so maybe this has already been considered. The only information I can find on set literals, though, assume {...} as a foregone conclusion, with various wrapped symbols like {/}, {@}, and {:} suggested to complement {}.) If we did use ∅ for an empty set, then f∅ could be the empty frozen set. -- Clint
If you are willing to accept {:} as an empty dict, then surely {,} would suffice as an empty set, with no backwards compatibility issues at all. Also, this is also not a new idea (https://mail.python.org/pipermail/python-3000/2006-April/001286.html). I don't know if this was never seriously considered further, or if it was formally rejected.
Compatibility issues could be resolved with a program which takes a Python program (codes) as a text and edits it.
It's not that simple. This would require changing the vast majority of Python scripts ever written, including code which has never and will never care about `set` objects. Depending on the setting would require version-control check-ins and probably code review. Is cleaning up a minor divergence from mathematical notation really worth that kind of churn? -- Clint
On 30 March 2018 at 02:04, Clint Hepner <clint.hepner@gmail.com> wrote:
I believe the main concern is that where "set()" is easy to look up in documentation, "{,}" isn't all that obvious (and isn't easy to search for), so folks would have to learn it by rote. It would also lead to the question of "If {,} is allowed for empty sets, why don't we allow (,) for empty tuples, and [,] for empty lists?". That said, a case could potentially be made for "Disambiguating empty container notation" that allowed all four options: * Unambiguous empty dict: {:} * Syntactic empty set: {,} * Empty tuple with optional comma: (,) * Empty list with optional comma: [,] Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Mar 30, 2018 at 2:42 AM, Julia Kim <julia.hiyeon.kim@gmail.com> wrote:
Unfortunately, that's not sufficient for backward compatibility. Imagine reading something on Stack Overflow that has this line of code in it: words = {} Does that make an empty set or an empty dict? How would anyone know? Are you going to go through every piece of code on Stack Overflow and change it? What about all the blogs out there? Printed books? Simply transforming code doesn't work. Having the same syntax perform drastically different things on different versions of the interpreter is almost certainly not going to fly. The only way that this might be usable is if you use a __future__ directive. And if it were done that way, I would expect most code out there to NOT use the directive, and therefore to keep today's semantics - which means the change effectively hasn't happened for most people. ChrisA
On Fri, Mar 30, 2018 at 3:00 AM, Stephan Houben <stephanh42@gmail.com> wrote:
Maybe, but that symbol generally means the unique immutable empty set in mathematics, so a closer equivalent would be frozenset(), in the same way that () gives you a singleton immutable empty tuple. But yes, I would like to some day have a literal for an empty set. Just not "{}". ChrisA
Mathematically, {1,2,3} is a unique, immutable set, too. {1,2,3} \union {4} doesn't modify {1,2,3}; it's just another way to represent another unique immutable set {1,2,3,4}. So I don't seen any problem (aside from the general resistance Unicode) with using ∅ to mean set(). However, just as string literals take a variety of prefixes (r, u, b, f), why can't set/dict literals? d{} == {} == dict() d{"a": 2} == {"a": 2} == dict(a=2) s{1,2,3} == {1,2,3} == set([1,2,3]) s{} == set() f{} == frozenset() f{1,2,3} == frozenset({1,2,3}) (I vaguely recall hearing a proposal to use o{...} for ordered dicts, so maybe this has already been considered. The only information I can find on set literals, though, assume {...} as a foregone conclusion, with various wrapped symbols like {/}, {@}, and {:} suggested to complement {}.) If we did use ∅ for an empty set, then f∅ could be the empty frozen set. -- Clint
If you are willing to accept {:} as an empty dict, then surely {,} would suffice as an empty set, with no backwards compatibility issues at all. Also, this is also not a new idea (https://mail.python.org/pipermail/python-3000/2006-April/001286.html). I don't know if this was never seriously considered further, or if it was formally rejected.
Compatibility issues could be resolved with a program which takes a Python program (codes) as a text and edits it.
It's not that simple. This would require changing the vast majority of Python scripts ever written, including code which has never and will never care about `set` objects. Depending on the setting would require version-control check-ins and probably code review. Is cleaning up a minor divergence from mathematical notation really worth that kind of churn? -- Clint
On 30 March 2018 at 02:04, Clint Hepner <clint.hepner@gmail.com> wrote:
I believe the main concern is that where "set()" is easy to look up in documentation, "{,}" isn't all that obvious (and isn't easy to search for), so folks would have to learn it by rote. It would also lead to the question of "If {,} is allowed for empty sets, why don't we allow (,) for empty tuples, and [,] for empty lists?". That said, a case could potentially be made for "Disambiguating empty container notation" that allowed all four options: * Unambiguous empty dict: {:} * Syntactic empty set: {,} * Empty tuple with optional comma: (,) * Empty list with optional comma: [,] Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (7)
-
Chris Angelico -
Chris Barker - NOAA Federal -
Clint Hepner -
Julia Kim -
Mark Lawrence -
Nick Coghlan -
Stephan Houben