I think it is fine if type(None)() returns None instead of raising an exception. On Fri, Jul 29, 2011 at 9:37 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
Consider:
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. --> for ins in ({0:'0'}, (1,), set([2, 3]), [4, 5], 6, 'seven', ... 8.0, True, None): ... print(type(ins)) ... type(ins)() ... <class 'dict'> {} <class 'tuple'> () <class 'set'> set() <class 'list'> [] <class 'int'> 0 <class 'str'> '' <class 'float'> 0.0 <class 'bool'> False <class 'NoneType'> Traceback (most recent call last): File "<stdin>", line 3, in <module> TypeError: cannot create 'NoneType' instances
I hit this issue when I had a dictionary of types to instantiate, one of which was NoneType.
Is there any reason why we shouldn't change these three to produce the singleton instance instead of raising an error?
Pro: They would then be consistent with every other built-in which will return either a new instance (int, str, float, etc), or the singleton instance that already exists (bool, and sometimes int & str), as well as no longer needing the `lambda:None` workaround (or worse, a try-except if you don't know what types are coming in).
Con: Might be code that relies on the exception being raised -- is anybody aware of any?
~Ethan~ _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)