Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #10458 > unrolled thread

NoneType and new instances

Back to article view | Back to comp.lang.python

Contents

  NoneType and new instances Ethan Furman <ethan@stoneleaf.us> - 2011-07-28 08:39 -0700
    Re: NoneType and new instances Billy Mays <81282ed9a88799d21e77957df2d84bd6514d9af6@myhashismyemail.com> - 2011-07-28 11:34 -0400
    Re: NoneType and new instances Ben Finney <ben+python@benfinney.id.au> - 2011-07-29 07:46 +1000
      Re: NoneType and new instances Ethan Furman <ethan@stoneleaf.us> - 2011-07-28 15:26 -0700
        Re: NoneType and new instances Ben Finney <ben+python@benfinney.id.au> - 2011-07-29 09:52 +1000
    Re: NoneType and new instances Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-29 11:16 +1000
      Re: NoneType and new instances Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-30 14:50 +1200
        Re: NoneType and new instances Terry Reedy <tjreedy@udel.edu> - 2011-07-30 09:35 -0400
        Re: NoneType and new instances python@bdurham.com - 2011-07-30 11:43 -0400
    Re: NoneType and new instances "bruno.desthuilliers@gmail.com" <bruno.desthuilliers@gmail.com> - 2011-07-30 09:39 -0700
      Re: NoneType and new instances Terry Reedy <tjreedy@udel.edu> - 2011-07-30 23:34 -0400
        Re: NoneType and new instances Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-31 14:28 +1000

#10458 — 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)()
...
<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

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~

[toc] | [next] | [standalone]

#10459

On 07/28/2011 11:39 AM, Ethan Furman wrote:
> <class 'NoneType'>
> Traceback (most recent call last):
> File "<stdin>", line 3, in <module>
> 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

[toc] | [prev] | [next] | [standalone]

#10485

Ethan Furman <ethan@stoneleaf.us> 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

[toc] | [prev] | [next] | [standalone]

#10487

Ben Finney wrote:
> Ethan Furman <ethan@stoneleaf.us> 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~

[toc] | [prev] | [next] | [standalone]

#10490

Ethan Furman <ethan@stoneleaf.us> writes:

> Ben Finney wrote:
> > Ethan Furman <ethan@stoneleaf.us> 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

[toc] | [prev] | [next] | [standalone]

#10493

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

[toc] | [prev] | [next] | [standalone]

#10567

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

[toc] | [prev] | [next] | [standalone]

#10578

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

[toc] | [prev] | [next] | [standalone]

#10584

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

[toc] | [prev] | [next] | [standalone]

#10587

On 28 juil, 17:39, Ethan Furman <et...@stoneleaf.us> 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

[toc] | [prev] | [next] | [standalone]

#10613

On 7/30/2011 12:39 PM, bruno.desthuilliers@gmail.com wrote:
> On 28 juil, 17:39, Ethan Furman<et...@stoneleaf.us>  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

[toc] | [prev] | [next] | [standalone]

#10614

Terry Reedy wrote:

> On 7/30/2011 12:39 PM, bruno.desthuilliers@gmail.com wrote:
>> On 28 juil, 17:39, Ethan Furman<et...@stoneleaf.us>  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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web