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

Groups > comp.lang.python > #83279

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

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

On 01/06/2015 06:31 PM, Chris Angelico wrote:
>
>> The type check issue is mostly about compatability in the first place ; eg:
>> users typecheck either unintentionally -- (novices syndrome) -- or because
>> they need all the capabilities of a given type, and the only simple way to
>> find out if they are all there are there is to typecheck.  eg: That's the
>> whole point of subclassing bool ... to let the user know they have at their
>> disposal (in a portable, simple way) all the features of the base type.
> Thing is, you're not fulfilling bool's contract, so it's better to not
> subclass, and just make your new type always falsy. If your users are
> type-checking bools, you might just have to let it break, and tell
> them not to do that.
>
> ChrisA

Explain; How does mere subclassing of bool break the contract that bool has?
eg: What method or data would the superclass have that my subclass would 
not?

Are you speaking about the quasi singleton nature of bool ?
If so, I spent a little time browsing my design patterns book by Gamma, 
Helm, Johnson, and Vlissides; and I'm looking at the singleton pattern 
on p.127.

The author writes, "Use the singleton pattern when:
-- There must be exactly one instance of a class, and it must be 
accessible to clients from a well-known access point.
-- When the _sole instance_ should be extensible by subclassing, and 
clients should be able to use an extended instance *without modifying 
their code*.
"

So, it's clear that in typical programming scenarios -- objects which 
are even more restrictive than bool by having only a single allowed 
instance rather than TWO -- are *Still* intentionally allowed to be 
subclassed for compatibility reasons.

And later in design patterns, the authors continue on:

"2. Subclassing the singleton class.
   The _main issue is not so much defining the subclass_ but installing 
its unique instance so that clients will be able to use it."

So, the general programming community is aware of the issue Rossum 
brings up about a singleton's subclass having an instance; it's just 
apparent that there are ways to work around the issue and preserve a 
singleton's character while still allowing a subclass.

So:  I'm really curious -- If subclassing is generally permitted for 
singletons as an industrial practice, why is it wrong to allow it in python?

I mean, If this is because Python doesn't support sub-classes for 
singletons, then it seems that Python is lacking something that should 
be added.

This isn't limited to bool, for as a library writer I might want to 
create a singleton class for my own purposes that has nothing to do with 
any of python's built in types.  And so, it would be appropriate to have 
a mechanism for subclassing user created singletons as well....

I already KNOW that 'C++' does have a workaround mechanism, as I've 
mentioned in a different e-mail, so that there's no reason to 
instantiate an instance of the subclass of a singleton if you don't want 
to.  That objection is really spurrious... so I really don't understand 
why Rossum cut off subclassability itself ... wasn't there any other way 
he could have prevented instantiation of subclasses without preventing 
the definition of a subclass itself?

I mean, even in python I can execute some methods of a class without 
actually INSTANTIATING that class.
eg:

import decimal
decimal.getcontext()

So, I don't understand your objection.
How does merely defining a subclass of bool violate the contract that 
bool puts out?

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Comparisons and sorting of a numeric class.... Andrew Robinson <andrew3@r3dsolutions.com> - 2015-01-06 19:37 -0800

csiph-web