On Sep 27, 5:33 am, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Sat, 27 Sep 2008 18:20:17 +1000, Ben Finney wrote: > > Steven D'Aprano <[EMAIL PROTECTED]> writes: > > >> On Fri, 26 Sep 2008 22:15:43 -0700, Aahz wrote: > >> > An ordinary singleton is instantiating the class multiple times yet > >> > returning the same instance object; a class singleton is simply using > >> > the class directly (like a module). > > > Where is this "class singleton" terminology from? > > I don't know. Googling on it brings up an awful lot of C++ and Java > source code for regular Singletons. Perhaps Aahz can shed some light on > it?
[snip] > In my example, the instance doesn't matter. I could write it like this: > > >>> class CallableAppendor(object): > > ... thing = (0, 1, 2) > ... @classmethod > ... def __call__(cls, *args): > ... return len(args + cls.thing) > ...>>> appendor = CallableAppendor() > >>> appendor.thing = (1, 2, 3, 4, 5, 6, 7, 8) > >>> appendor(1, 2, 4, 8, 16) > 8 > >>> CallableAppendor.__call__(1,2,4,8,16) > > 8 > > but what's the purpose of instantiating the class? I've used them (class singletons, adopting the term) as a Globals namespace, but only to the end of tidying. It makes it easy to reassign immutables. It is too bad 'CallableAppendor.__call__(1,2,4,8,16)' doesn't work as expected. That is, 'CallableAppendor(1,2,4,8,16)' dosen't call '__call__'. I have a workaround, which may be just what you're looking for. >>> class A(type): ... def __call__( self, *ar ): ... print 'call', self, ar ... >>> class B(object): ... __metaclass__= A ... >>> B(3) call <class '__main__.B'> (3,) Overriding the __call__ method of 'type' has the effect of giving you a static __call__ method on a class-- a method which doesn't need an instance to call. Your behavior may be counterintuitive though, to someone who wants to instantiate 'B', in this case, and proceed like a normal object. That is, they want to call a generic class and use it, and also expect instances of B to behave as B. You can't have both, so either return B from B.__new__, or, to instantiate B, take the long way and call B.__new__ directly. >>> B.__new__(B) <__main__.B object at 0x009FDB70> Has anyone stepped through the C code to find out when the decision is made to call which function, B.__new__ or A.__call__, when B is called? I'm happy that overriding type.__call__ produced the intended results; it's always nice when things go right. -- http://mail.python.org/mailman/listinfo/python-list
