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?
--
https://mail.python.org/mailman/listinfo/python-list
