On Fri, 2007-03-16 at 01:50 +1100, Edward d'Auvergne wrote: > On 3/16/07, Chris MacRaild <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-03-16 at 01:00 +1100, Edward d'Auvergne wrote: > > > On 3/15/07, Chris MacRaild <[EMAIL PROTECTED]> wrote: > > > > On Thu, 2007-03-15 at 00:09 +1100, Edward d'Auvergne wrote: > > > > > On 3/14/07, Chris MacRaild <[EMAIL PROTECTED]> 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!
This is all true, but misses the point. a and b are different objects, but they are of the same type: >>> type(a) is type(b) True and both of them are instances of the parent class A. So to go back to where we started: for almost any implimentation of Singleton >>> single = Singleton() >>> class Sub(Singleton): pass ... >>> sub = Sub() >>> isinstance(sub,Singleton) True >>> isinstance(single,Singleton) True >>> sub is single False This breaches the Singleton design because we have two *different* objects that are both instances of the Singleton class. To put this in terms of the favourite metaphore, because apple is a subclass of fruit, all apples are also fruits (ie. all instances of class Apple in also instances of class Fruit). Even if you have several different apples, this does not make them any less fruity. Instance refers to a non-exclusive relationship between class and object: many different objects can be instances of the same class and any one object can be an instance of many different classes. Inheritance is the mechanism of this non-exclusivity; Singlton seeks to limit it. Hence the two are incompatible when applied to the same object. Chris > > Edward > _______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
