NoneType and new instances
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)()
...
{}
()
set()
[]
0
''
0.0
False
Traceback (most recent call last):
File "", line 3, in
TypeError: cannot create 'NoneType' instances
Why is NoneType unable to produce a None instance? I realise that None
is a singleton, but so are True and False, and bool is able to handle
returning them:
--> bool(0) is bool(0)
True
This feels like a violation of 'Special cases aren't special enough to
break the rules.'
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
On 07/28/2011 11:39 AM, Ethan Furman wrote: Traceback (most recent call last): File "", line 3, in TypeError: cannot create 'NoneType' instances Why is NoneType unable to produce a None instance? I realise that None is a singleton, but so are True and False, and bool is able to handle returning them: --> bool(0) is bool(0) True This feels like a violation of 'Special cases aren't special enough to break the rules.' ~Ethan~ Probably for the same reason Ellipsis and NotImplemented also can't be instantiated. What that reason is I don't know. Related: http://bugs.python.org/issue6477#msg90641 -- Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
On Thu, Jul 28, 2011 at 9:39 AM, Ethan Furman wrote: > Why is NoneType unable to produce a None instance? I realise that None is a > singleton, but so are True and False, and bool is able to handle returning > them: The bool constructor works (actually just returns one of the existing singletons) so that you can do things like this: truth_value = bool(x + 5) return my_dict[truth_value] Why would you ever need to instantiate NoneType? -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Ian Kelly wrote:
On Thu, Jul 28, 2011 at 9:39 AM, Ethan Furman wrote:
Why is NoneType unable to produce a None instance? I realise that None is a
singleton, but so are True and False, and bool is able to handle returning
them:
The bool constructor works (actually just returns one of the existing
singletons) so that you can do things like this:
truth_value = bool(x + 5)
return my_dict[truth_value]
Why would you ever need to instantiate NoneType?
I'm glad you asked! I'm using dictionaries to describe fields and what
their return values should be. There happen to be two special cases:
empty and Null. So a portion of the dictionary looks like:
fielddef = { 'empty':some_func, 'null':some_func }
Depending on the needs of the user, `some_func` might be `str`, `int`,
`custom_class`, or `NoneType`. Somewhere else in the code I have:
if not value: # or some such
cls = fielddef['empty']
return cls()
This works for *everything* except NoneType. grrr. ;)
~Ethan~
PS
I'll use a lambda to get around it, but that's not very elegant. Why
shouldn't NoneType be able to return the singleton None?
--
http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
On Fri, Jul 29, 2011 at 7:03 AM, Ethan Furman wrote: > I'll use a lambda to get around it, but that's not very elegant. Why > shouldn't NoneType be able to return the singleton None? Why a lambda? def ThisFunctionWillReturnNone(): pass Although, since the returning of None is crucial to it, it'd probably be better to explicitly "return None". But minimalist useful functions are amusing. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Ethan Furman writes: > Why is NoneType unable to produce a None instance? I realise that None > is a singleton That answers your question. Because None is a singleton, the job of its type is to make sure there are no other instances. > but so are True and False, and bool is able to handle returning them: Well, they don't meet the definition of a singleton, because there are two instances of ‘bool’ :-) There may be code out there which depends on the fact that there once was never a ‘bool’ type, or depends on the fact that bools are also ‘int’ instances, and it's been deemed not-worth-the-trouble to break that code. > This feels like a violation of 'Special cases aren't special enough to > break the rules.' In the case of ‘bool’, the rule was broken before being introduced. -- \ “Isn't it enough to see that a garden is beautiful without | `\ having to believe that there are fairies at the bottom of it | _o__) too?” —Douglas Adams | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Chris Angelico wrote: On Fri, Jul 29, 2011 at 7:03 AM, Ethan Furman wrote: I'll use a lambda to get around it, but that's not very elegant. Why shouldn't NoneType be able to return the singleton None? Why a lambda? def ThisFunctionWillReturnNone(): pass Although, since the returning of None is crucial to it, it'd probably be better to explicitly "return None". But minimalist useful functions are amusing. More amusing still: def NoneType(): "Returns None" ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Ben Finney wrote: Ethan Furman writes: Why is NoneType unable to produce a None instance? I realise that None is a singleton That answers your question. Because None is a singleton, the job of its type is to make sure there are no other instances. Which it can do quite easily by returning the single instance of None -- it is not necessary to raise an exception to fulfill its duty. but so are True and False, and bool is able to handle returning them: Well, they don't meet the definition of a singleton, because there are two instances of ‘bool’ :-) Okay, a slightly relaxed definition of singleton, since there is only ever one instance with the value of True, or the value of False; likewise, there is only ever one instance with the value of None. This feels like a violation of 'Special cases aren't special enough to break the rules.' In the case of ‘bool’, the rule was broken before being introduced. I think we disagree on what the rule is. I see it as "Return an instance if you can." Nobody has yet pointed out a good reason on why NoneType, NotImplementedType, and ellipsis (to be thorough ;) cannot or should not return the single instance that exists, when every other built-in will return either a new object, or the single object that exists for that value. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Ethan Furman writes: > Ben Finney wrote: > > Ethan Furman writes: > >> This feels like a violation of 'Special cases aren't special enough > >> to break the rules.' > > > > In the case of ‘bool’, the rule was broken before being introduced. > > I think we disagree on what the rule is. I see it as "Return an instance > if you can." That's not the rule for singletons, though. You've already said what the rule is: > Nobody has yet pointed out a good reason on why NoneType, > NotImplementedType, and ellipsis (to be thorough ;) cannot or should > not return the single instance that exists So we agree on what the rule is. The ‘bool’ type breaks that rule, for the reasons given earlier. You may want to advocate for a *change* to that rule, or what the rule *should be*, but that's a different issue. > when every other built-in will return either a new object, or the > single object that exists for that value. What other built-in singleton types are there? -- \“It's all in the mind, you know.” —The Goon Show | `\ | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Ethan Furman wrote: > Why is NoneType unable to produce a None instance? I realise that None > is a singleton, but so are True and False, and bool is able to handle > returning them: I've asked this question myself. As I recall the answer, it's just a matter of personal preference. Some people consider that singletons should raise an error if you try to instantiate them a second time. I think that's the "standard" behaviour referenced in the Gang Of Four design patterns book, and it's certainly very common in Java. Others think that it should just return the same instance. The advantage of raising an error is that if the singleton holds state, then the caller won't be fooled into thinking they got a second instance. They have to explicitly refer to the one instance each time. But since None doesn't hold state, there is no advantage here. As for True and False, bool has to be able to return them, because the whole purpose of exposing bool is so people can call it: if bool(some_value) was an error, that would defeat the purpose of having bool! -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Ian Kelly wrote: > Why would you ever need to instantiate NoneType? Well, you probably wouldn't deliberately, but if you have code like this: types = [type(x) for x in list_of_objects] # later on... for t in types: instance = t() do_something_with(instance) it would be nice if it didn't explode when list_of_objects contains None. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Chris Angelico wrote:
> On Fri, Jul 29, 2011 at 7:03 AM, Ethan Furman wrote:
>> I'll use a lambda to get around it, but that's not very elegant. Why
>> shouldn't NoneType be able to return the singleton None?
>
> Why a lambda?
>
> def ThisFunctionWillReturnNone():
> pass
This is a good use-case for a lambda. Ethan's use-case is a dict of
constructors:
fielddef = { 'empty':some_func, 'null':some_func }
There's no need to expose the constructor outside of the dict, hence:
fielddef = { 'empty': str, 'null': lambda: None }
does the job. No need for a top-level named function.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
On 7/28/2011 5:03 PM, Ethan Furman wrote:
I'm glad you asked! I'm using dictionaries to describe fields and
what their return values should be. There happen to be two special
cases: empty and Null. So a portion of the dictionary looks like:
fielddef = { 'empty':some_func, 'null':some_func }
Depending on the needs of the user, `some_func` might be `str`,
`int`, `custom_class`, or `NoneType`. Somewhere else in the code I
have:
if not value: # or some such cls = fielddef['empty'] return cls()
This works for *everything* except NoneType. g
~Ethan~
PS I'll use a lambda to get around it, but that's not very elegant.
Why shouldn't NoneType be able to return the singleton None?
Possibly historical accident. You could ask on python-ideas
or put a feature request on the tracker. Start with the first in case
there is a ready answer I do not know of.
The big question is whether there is code depending on current behavior.
--
http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Steven D'Aprano wrote: As for True and False, bool has to be able to return them, because the whole purpose of exposing bool is so people can call it: if bool(some_value) was an error, that would defeat the purpose of having bool! Bool is different, because it doubles as a function for coercing things to bool. There's no corresponding concept of coercing something to None, or Ellipsis, etc. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Ethan's proposal was accepted on python-ideas. In Python 3.3, the classes for the singletons None, Ellipsis, and NotImplemented will be callables that return the singleton. It turns out that the reason an exception is now raised is that there currently is no .__new__ method, so an exception is raised by default. .__new__ methods returning the singleton have been added. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Hi Terry, > Ethan's proposal was accepted on python-ideas. In Python 3.3, the classes for > the singletons None, Ellipsis, and NotImplemented will be callables that > return the singleton. Thanks for sharing this news. Its motivating to see this type of feedback loop because it encourages others (myself included!) to become more involved in the process. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
On 28 juil, 17:39, Ethan Furman wrote: > > --> bool(0) is bool(0) > True > This test is not reliable - a same id can be reused for terms (I have already seen such things happening). If you want a reliable test, use: #> a = bool(0) #> b = bool(0) #> a is b True Note that this still fails to prove anything since bool is a subclass of int and CPython caches "small" integers: #> a = 42 #> b = 42 #> a is b True -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
On 7/30/2011 12:39 PM, bruno.desthuilli...@gmail.com wrote: On 28 juil, 17:39, Ethan Furman wrote: --> bool(0) is bool(0) True This test is not reliable It is in the sense that it will always work -- because False/True are doubletone constants and so documented. But expr is expr == True does not reliably say it will always be true, because > - a same id can be reused for terms (I have already seen such things happening). If you want a reliable test, use: #> a = bool(0) #> b = bool(0) #> a is b True Note that this still fails to prove anything since bool is a subclass of int and CPython caches "small" integers: #> a = 42 #> b = 42 #> a is b True -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Terry Reedy wrote: > On 7/30/2011 12:39 PM, bruno.desthuilli...@gmail.com wrote: >> On 28 juil, 17:39, Ethan Furman wrote: >>> >>> --> bool(0) is bool(0) >>> True > >> This test is not reliable > > It is in the sense that it will always work -- because False/True are > doubletone constants and so documented. Surely that should be doubleton :) 2.2: True and False released as names for 1 and 0; bool was a built-in function, but not a type. 2.3: bool promoted to a type; True and False actual bools. The documentation claims that there's only one instance of each. I'm sure that I remember a short period during which Python had bools, but didn't guarantee that there would only be one instance of True and one of False, but I'm damned if I can find any evidence of this. Am I confabulating? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
