On 3/16/07, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> wrote:
On Fri, 2007-03-16 at 01:00 +1100, Edward d'Auvergne wrote:
> On 3/15/07, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> wrote:
> > On Thu, 2007-03-15 at 00:09 +1100, Edward d'Auvergne wrote:
> > > On 3/14/07, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> wrote:
> > > > On Tue, 2007-03-13 at 19:51 +1100, Edward d'Auvergne wrote:
> > > > > Gary,
> > > > >
> > > > > I've written some unit tests which are located in the file
> > > > > 'test_suite/unit_tests/data/__init__.py'. Would you know what
> > > > > modifications I need to apply to make these tests run? These tests
> > > > > are for the methods of the Data singleton class (the relax data
> > > > > storage object) which is located in 'data/__init__.py'. I haven't
> > > > > used the statement 'from x import Data' for this class so it is the
> > > > > legal and ubiquitous usage of an __init__.py file. Would
> > > > > 'unit_test_runner.py' handle this code?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Edward
> > > > >
> > > > >
> > > > > P.S. These tests demonstrate the utility of subclassing the
singleton
> > > > > and is one reason I was arguing for the use of the class import
rather
> > > > > than reference import.
> > > > >
> > > >
> > > > It is of course correct that the Singleton implimentation I proposed
> > > > does not allow for subclassing. This however might well be seen as a
> > > > design feature, given the well known conceptual problems with
> > > > subclassing Singleton. Essentially, subclassing violates the Singleton
> > > > Design Pattern:
> > > >
> > > > class Singleton:
> > > > def __new__(self):
> > > > ...
> > > >
> > > > class Sub(Singleton): pass
> > > >
> > > > >>> a = Singleton()
> > > > >>> b = Sub()
> > > > >>> isinstance(a,Singleton)
> > > > True
> > > > >>> isinstance(b,Singleton)
> > > > True
> > > > >>> a is b
> > > > False
> > > > >>> a == b
> > > > False
> > > >
> > > > ie. we have 2 instances of Singleton that are not the same thing, and
> > > > not even equal! If this is the behaviour you want, then you need
> > > > something other than Singleton. On the other hand, if you really want
> > > > Singleton, then you can't also hope for subclassability.
> > >
> > > Actually one is an instance of Singleton and the other is an instance
> > > of Sub.
> >
> > The definition of inheritance is that an instance of the subclass is
> > also an instance of the parent class. ie. b is an instance of both Sub
> > and Singleton. Inheritance from a Singleton class is therefore a logical
> > contradiction.
>
> That is actually incorrect!
Sorry to drag this on, but I'm not incorrect here, and its a fairly
fundamental point of OO philosophy and practice that is well worth
getting right. This is pasted directly from my Python command line (the
interpreter does not lie!):
>>> class A: pass
...
>>> class B(A): pass
...
>>> a= A()
>>> b = B()
>>> isinstance(a,A)
True
>>> isinstance(a,B)
False
>>> isinstance(b,B)
True
>>> isinstance(b,A)
True
Because B is a subclass of A, all instances of B are also instances of A
The 'isinstance()' built-in function will return true if object x is
an instance of the supplied class or, importantly, a subclass. This
is what it's docstring says. Try the following instead (after
reissuing the above statements):
a is b
False
hash(a)
-1217311764
hash(b)
-1214788020
id(a)
-1217311764
id(b)
-1214788020
If b was the same instance as a, then the first statement would return
true. The two hash() statements show that a and b are different. The
two id() statements show that they occupy different locations in
memory - the number is the object's memory address. Another test is
populating the empty containers:
a.x = 1
b.y = 2
dir(a)
['__doc__', '__module__', 'x']
dir(b)
['__doc__', '__module__', 'y']
The instances a and b are very much different!
Edward
Re: Vote for the design of the relax data storage object singleton.