An unambiguous way of initializing an empty dictionary and set

Currently: l = [] # new empty list t = () # new empty tuple s = set() # new empty set (no clean and consistent way of initializing regarding the others) <<< d = {} # new empty dictionary Possible solution: s = {} # new empty set d = {:} # new empty dictionary (the ":" is a reference to key-value pairs) Current workaround at least for consistency: l = list() # new empty list t = tuple() # new empty tuple s = set() # new empty set d = dict() # new empty dictionary However, it doesn't feel right to not be able to initialize an empty set as cleanly and consistently as lists, tuples and dictionaries in both forms.

This would be fine for a new language. But completely out of the question for Python — it would break an enormous amount of code. We are in this position because sets are relatively new to Python, and there are only so many brackets. Current workaround at least for consistency:
It may not “feel” right, but is it that big a deal? There are literally any number of types that can’t be initialized with a “literal” — so consistence is not compelling here. set() is (maybe?) the only builtin, but is initializing and empty set that common? Note, there was a recent thread on this list about a literal for frozenset — I think: f{} was proposed— you may want to revive that -and add s{} for an empty set … Though i personally wouldn’t support the idea. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

Oops, didn’t notice this wasn’t Python-ideas — that’s where it should be. -CHB On Sun, Mar 13, 2022 at 3:44 PM Christopher Barker <pythonchb@gmail.com> wrote:
-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On 3/13/2022 5:49 PM, joao.p.f.batista.97@gmail.com wrote:
This is such a good idea that many people, including myself, have already had it, and even more agree that this would be the proper way for a new language. But as already discussed on python-ideas, this change would break possibly millions of programs, and we will will not do that. Please don't futilely push this further.
Anyone who values consistency can pay the price of this in ones own code. If you have questions, python-list would be the appropriate place. -- Terry Jan Reedy

This would be fine for a new language. But completely out of the question for Python — it would break an enormous amount of code. We are in this position because sets are relatively new to Python, and there are only so many brackets. Current workaround at least for consistency:
It may not “feel” right, but is it that big a deal? There are literally any number of types that can’t be initialized with a “literal” — so consistence is not compelling here. set() is (maybe?) the only builtin, but is initializing and empty set that common? Note, there was a recent thread on this list about a literal for frozenset — I think: f{} was proposed— you may want to revive that -and add s{} for an empty set … Though i personally wouldn’t support the idea. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

Oops, didn’t notice this wasn’t Python-ideas — that’s where it should be. -CHB On Sun, Mar 13, 2022 at 3:44 PM Christopher Barker <pythonchb@gmail.com> wrote:
-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On 3/13/2022 5:49 PM, joao.p.f.batista.97@gmail.com wrote:
This is such a good idea that many people, including myself, have already had it, and even more agree that this would be the proper way for a new language. But as already discussed on python-ideas, this change would break possibly millions of programs, and we will will not do that. Please don't futilely push this further.
Anyone who values consistency can pay the price of this in ones own code. If you have questions, python-list would be the appropriate place. -- Terry Jan Reedy
participants (5)
-
Christopher Barker
-
Ethan Furman
-
Jeremiah Vivian
-
joao.p.f.batista.97@gmail.com
-
Terry Reedy