change NoneType, NotImplementedType, & ellipses to return the appropriate singleton
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~
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)
Am 07.08.2011 01:34, schrieb dag.odenhall@gmail.com:
On 29 July 2011 19:03, Guido van Rossum <guido@python.org> wrote:
I think it is fine if type(None)() returns None instead of raising an exception.
+1, I've often wanted it and felt (lambda: None) was somewhat clunky.
It makes its intent much clearer than type(None) though. Georg
Does it? What else would you use type(None) for? An isinstance() check? Devin On Sun, Aug 7, 2011 at 4:12 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Am 07.08.2011 01:34, schrieb dag.odenhall@gmail.com:
On 29 July 2011 19:03, Guido van Rossum <guido@python.org> wrote:
I think it is fine if type(None)() returns None instead of raising an exception.
+1, I've often wanted it and felt (lambda: None) was somewhat clunky.
It makes its intent much clearer than type(None) though.
Georg
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Frankly, type(None) only exists in the language because all objects have a type, and have to be introspectable in a uniform manner. This is occasionally useful to introspection code, but of no practical consequence for most users. Using type(None) as a cheap alternative to lambda:None strikes me as an invitation for unreadable code -- since type(None) doesn't have much of a practical purpose, users have no expectation of what it would do (even though you can reason it out). --Guido On Sun, Aug 7, 2011 at 9:07 AM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
Does it? What else would you use type(None) for? An isinstance() check?
Devin
On Sun, Aug 7, 2011 at 4:12 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Am 07.08.2011 01:34, schrieb dag.odenhall@gmail.com:
On 29 July 2011 19:03, Guido van Rossum <guido@python.org> wrote:
I think it is fine if type(None)() returns None instead of raising an exception.
+1, I've often wanted it and felt (lambda: None) was somewhat clunky.
It makes its intent much clearer than type(None) though.
Georg
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
Well, I wouldn't use it for anything. Georg Am 07.08.2011 15:07, schrieb Devin Jeanpierre:
Does it? What else would you use type(None) for? An isinstance() check?
Devin
On Sun, Aug 7, 2011 at 4:12 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Am 07.08.2011 01:34, schrieb dag.odenhall@gmail.com:
On 29 July 2011 19:03, Guido van Rossum <guido@python.org> wrote:
I think it is fine if type(None)() returns None instead of raising an exception.
+1, I've often wanted it and felt (lambda: None) was somewhat clunky.
It makes its intent much clearer than type(None) though.
Georg
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Is there any reason not to allow similar behaviour for True and False? i.e. True() == True On Aug 7, 2011 3:39 PM, "Georg Brandl" <g.brandl@gmx.net> wrote:
Well, I wouldn't use it for anything.
Georg
Am 07.08.2011 15:07, schrieb Devin Jeanpierre:
Does it? What else would you use type(None) for? An isinstance() check?
Devin
On Sun, Aug 7, 2011 at 4:12 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Am 07.08.2011 01:34, schrieb dag.odenhall@gmail.com:
On 29 July 2011 19:03, Guido van Rossum <guido@python.org> wrote:
I think it is fine if type(None)() returns None instead of raising an exception.
+1, I've often wanted it and felt (lambda: None) was somewhat clunky.
It makes its intent much clearer than type(None) though.
Georg
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 2011-08-07, at 18:37 , David Townshend wrote:
Is there any reason not to allow similar behaviour for True and False? i.e. True() == True As far as I undersand, that's not the proposal for NoneType (or NotImplementedType or ellipsis) at all.
You're suggesting that the *value* could be callable (and return itself), the proposal is about *types*, and them becoming "normal" (callable) types: currently, if you get a hold of NoneType, NotImplementedType or ellipsis (generally via a call to `type`) you can not use it to get an instance of that class back: >>> type(None)() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot create 'NoneType' instances >>> type(NotImplemented)() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot create 'NotImplementedType' instances >>> type(...)() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot create 'ellipsis' instances This proposal is merely about removing this forbidding. Booleans don't have this issue: `bool` is already a normal (callable) type, and returns `False` when called without arguments.
On 2011-08-07, at 18:37 , David Townshend wrote:
Is there any reason not to allow similar behaviour for True and False? i.e. True() == True As far as I undersand, that's not the proposal for NoneType (or NotImplementedType or ellipsis) at all.
You're suggesting that the *value* could be callable (and return itself),
Ah, sorry - I didn't read it properly! On Aug 7, 2011 6:46 PM, "Masklinn" <masklinn@masklinn.net> wrote: the proposal is about *types*, and them becoming "normal" (callable) types: currently, if you get a hold of NoneType, NotImplementedType or ellipsis (generally via a call to `type`) you can not use it to get an instance of that class back:
type(None)() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot create 'NoneType' instances type(NotImplemented)() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot create 'NotImplementedType' instances type(...)() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot create 'ellipsis' instances
This proposal is merely about removing this forbidding.
Booleans don't have this issue: `bool` is already a normal (callable)
type, and returns `False` when called without arguments.
That looks pretty reasonable to me, and, more importantly, would increase consistency as you point out :) (I have had a similar issue in the past, where I expected this to work but it didn't -- so I replaced NoneType with lambda: None.) cheers lvh
Ethan Furman wrote:
<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?
+0.5 -- Steven
On 7/29/2011 12:37 PM, Ethan Furman wrote:
Is there any reason why we shouldn't change these three to produce the singleton instance instead of raising an error?
You have all the approvals you need (congrats), so file a feature request and mention this thread or even better, add a iink mail.python.org/<whatever)
On 7/29/2011 7:41 PM, Terry Reedy wrote:
On 7/29/2011 12:37 PM, Ethan Furman wrote:
Is there any reason why we shouldn't change these three to produce the singleton instance instead of raising an error?
You have all the approvals you need (congrats), so file a feature request and mention this thread or even better, add a iink mail.python.org/<whatever)
Cancel that. Benjamin just did it already.
On Jul 29, 2011, at 4:41 PM, Terry Reedy wrote:
On 7/29/2011 12:37 PM, Ethan Furman wrote:
Is there any reason why we shouldn't change these three to produce the singleton instance instead of raising an error?
You have all the approvals you need (congrats), so file a feature request and mention this thread or even better, add a iink mail.python.org/<whatever)
Too slow :-) Benjamin already implemented it and checked it in 20 minutes before your post. Never race a time machine, Raymond
Raymond Hettinger wrote:
On Jul 29, 2011, at 4:41 PM, Terry Reedy wrote:
On 7/29/2011 12:37 PM, Ethan Furman wrote:
Is there any reason why we shouldn't change these three to produce the singleton instance instead of raising an error? You have all the approvals you need (congrats), so file a feature request and mention this thread or even better, add a iink mail.python.org/<whatever)
Too slow :-) Benjamin already implemented it and checked it in 20 minutes before your post.
Awesome. :) ~Ethan~
Ethan Furman <ethan@stoneleaf.us> writes:
Raymond Hettinger wrote:
On Jul 29, 2011, at 4:41 PM, Terry Reedy wrote:
On 7/29/2011 12:37 PM, Ethan Furman wrote:
Is there any reason why we shouldn't change these three to produce the singleton instance instead of raising an error?
You have all the approvals you need (congrats), so file a feature request […]
Too slow :-) Benjamin already implemented it and checked it in 20 minutes before your post.
Awesome. :)
Congratulations, and thanks for taking this through the right channels. -- \ “It is undesirable to believe a proposition when there is no | `\ ground whatever for supposing it true.” —Bertrand Russell, _The | _o__) Value of Scepticism_, 1928 | Ben Finney
participants (15)
-
Antoine Pitrou -
Ben Finney -
dag.odenhall＠gmail.com -
David Townshend -
Devin Jeanpierre -
Ethan Furman -
Georg Brandl -
Guido van Rossum -
Laurens Van Houtven -
Masklinn -
MRAB -
Raymond Hettinger -
Stefan Behnel -
Steven D'Aprano -
Terry Reedy