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

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

Re: Comparisons and sorting of a numeric class....

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-13 09:35 +1100
    Re: Comparisons and sorting of a numeric class.... Steven D'Aprano <steve@pearwood.info> - 2015-01-13 04:57 +0000
      Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-13 16:30 +1100

#83644 — Re: Comparisons and sorting of a numeric class....

On Tue, Jan 13, 2015 at 9:27 AM, Andrew Robinson
<andrew3@r3dsolutions.com> wrote:
> Huh? I'm not adding any values when I merely subclass bool ; and even if the
> subclass could be instantiated -- that's doesn't mean a new value or
> instance of the base class (bool) must exist.  For I could happily work with
> a new subclass that contains no new data, but only an already existing
> instance of 'True' or 'False' as its value source.   That means there is no
> new value...  but at most (and even that could be worked around) a new
> instance of a subclass containing an existing instance of it's base class.

If you subclass bool and instantiate your subclass, you have made a
new instance of bool, because every instance of a subclass is an
instance of its superclass. The Python bool type has the following
invariant, for any object x:

assert not isinstance(x, bool) or x is True or x is False

(You can fiddle with this in Py2 by rebinding the names True and
False, but you could replace those names with (1==1) and (1==0) if you
want to be completely safe. Likewise, the name "bool" could be
replaced with (1==1).__class__ to avoid any stupidities there. But
conceptually, that's the invariant.)

Subclassing bool breaks this invariant, unless you never instantiate
the subclass, in which case it's completely useless.

ChrisA

[toc] | [next] | [standalone]

#83658

On Tue, 13 Jan 2015 09:35:43 +1100, Chris Angelico wrote:

> Subclassing bool breaks this invariant, unless you never instantiate the
> subclass, in which case it's completely useless.

Not necessarily. A class that you never instantiate, but use as an object 
itself, is another way of implementing the singleton design pattern. 
Obviously all the methods have to be class methods, but it is doable.

But wacky exceptions like subclasses that aren't instantiated aside, 
normally if you subclass something you intend to instantiate it.

In Java terms bool is a "final" class which means it cannot be subclassed. 
Although Python is not anywhere near as restrictive as Java, and makes a 
virtue out of allowing the programmer to shot themselves in the foot, 
there are some restrictions and this is one of them.


-- 
Steven

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

#83659

On Tue, Jan 13, 2015 at 3:57 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 13 Jan 2015 09:35:43 +1100, Chris Angelico wrote:
>
>> Subclassing bool breaks this invariant, unless you never instantiate the
>> subclass, in which case it's completely useless.
>
> Not necessarily. A class that you never instantiate, but use as an object
> itself, is another way of implementing the singleton design pattern.
> Obviously all the methods have to be class methods, but it is doable.
>
> But wacky exceptions like subclasses that aren't instantiated aside,
> normally if you subclass something you intend to instantiate it.

True, I should have said "probably useless" instead of "completely
useless". :) There's always *something* you could do with it.

ChrisA

[toc] | [prev] | [standalone]

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

csiph-web