Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Classes and modules are singletons?

1 view
Skip to first unread message

Steven D'Aprano

unread,
Mar 5, 2008, 8:44:30 PM3/5/08
to
I recall that Python guarantees that module objects are singletons, and
that this must hold for any implementation, not just CPython: you can
only ever create one instance of a module via the import mechanism. But
my google-foo is obviously weak today, I cannot find where the Python
language reference guarantees that. Can somebody please point me at the
link making that guarantee?

(Note: you can create multiple modules with the same name and state using
new.module. I don't think that counts, although it may be a good way to
win bar bets with your Python buddies.)


But what about classes? Are they singletons? Obviously classes aren't
Singleton classes, that is, given an arbitrary class C you can create
multiple instances of C. But what about class objects themselves? I've
found a few odd references to "classes are singletons", but nothing in
the language reference.

I've done some experimentation, e.g.:

>>> import module
>>> from module import Class
>>> module.Class is Class
True


but I'm not sure if that's (1) meaningful or (2) implementation-specific.


--
Steven

Terry Reedy

unread,
Mar 5, 2008, 9:05:31 PM3/5/08
to pytho...@python.org

"Steven D'Aprano" <st...@REMOVE-THIS-cybersource.com.au> wrote in message
news:13suj3u...@corp.supernews.com...

If I understand your question, classes are not singletons:
>>> ll=[]
>>> for i in range(2):
import string
ll[i]=string

>>> ll[0] is ll[1]
True
>>> for i in range(2):
class C: pass
ll[i] = C


>>> ll[0] is ll[1]
False

tjr

Steven D'Aprano

unread,
Mar 5, 2008, 9:31:58 PM3/5/08
to
On Wed, 05 Mar 2008 21:05:31 -0500, Terry Reedy wrote:


> If I understand your question, classes are not singletons:
>>>> ll=[]
>>>> for i in range(2):
> import string
> ll[i]=string

Where's the IndexError? :-)

>>>> ll[0] is ll[1]
> True

But yes, modules are singletons in that way, at least if you go through
the import mechanism.


>>>> for i in range(2):
> class C: pass
> ll[i] = C
>
>
>>>> ll[0] is ll[1]
> False


Ah, but each time around the loop you create a *new class* that just
happens to be called C. An alternative way to see similar behaviour is:


def foo(x=None):
class C(object):
X = x
return C

Naturally foo() is foo() gives False -- although both classes are called
C, they are different classes that just happen to have the same state.


I accept my question about classes being singletons is not well-formed,
not even in my own mind. I guess one way of asking is, for any two class
objects (not instances) C1 and C2, does "C1 == C2" imply "C1 is C2"?


--
Steven

Micah Cowan

unread,
Mar 5, 2008, 10:38:50 PM3/5/08
to
Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> writes:

> I recall that Python guarantees that module objects are singletons, and
> that this must hold for any implementation, not just CPython: you can
> only ever create one instance of a module via the import mechanism. But
> my google-foo is obviously weak today, I cannot find where the Python
> language reference guarantees that. Can somebody please point me at the
> link making that guarantee?


It's not an absolute strict guarantee; it's just implied by the fact
that "import" uses any appropriate objects already found in
sys.modules.

>>> import sys
>>> ll = []
>>> for i in range(2):
... import string
... ll.append(string)
... del sys.modules['string']
...

>>> ll[0] is ll[1]
False

(I'm sure there are very good reasons never to do what I just did there.)

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

casti...@gmail.com

unread,
Mar 5, 2008, 10:43:52 PM3/5/08
to
On Mar 5, 8:31 pm, Steven D'Aprano <st...@REMOVE-THIS-

>>> class metaC( type ):
... def __eq__( self, other ):
... return random.choice([ True, False ])
...
>>> class C( metaclass= metaC ):
... pass
...
>>> import random
>>> C==C
True
>>> C==C
False
>>> C==C
False
>>> C==C
True
>>> C==C
False
>>>

You made me think of this. What relevance it has is open to
debate. ...In a separate thread.

http://en.wikipedia.org/wiki/Relevance

It's my Signal-channel signal signal.

casti...@gmail.com

unread,
Mar 5, 2008, 10:51:35 PM3/5/08
to
> > > If I understand your question, classes are not singletons:
> > >>>> ll=[]
> > >>>> for i in range(2):
> > >  import string
> > >  ll[i]=string
>
> > Where's the IndexError? :-)
>
> > I accept my question about classes being singletons is not well-formed,
> > not even in my own mind. I guess one way of asking is, for any two class
> > objects (not instances) C1 and C2, does "C1 == C2" imply "C1 is C2"?


Similarly, no.

>>> class metaC( type ):
... def __eq__( self, other ):

... return True


...
>>> class C( metaclass= metaC ):
... pass
...

>>> class D( metaclass= metaC ):
... pass
...
>>> C==D
True
>>> C is D
False

+1 raised eyebrow

casti...@gmail.com

unread,
Mar 5, 2008, 11:35:02 PM3/5/08
to

Well, you're not going to believe me, but a <scaryword>"bar"</
scaryword> just had an idea.

Don't forget:


class C( metaclass= metaC )

class metaC( metaclass= metametaC )
class metametaC( type ): bor hor hor.

Now for the academics, is it telling a joke? If so, that's pretty
fine--- but.

casti...@gmail.com

unread,
Mar 6, 2008, 1:25:27 AM3/6/08
to
> I accept my question about classes being singletons is not well-formed,
> not even in my own mind. I guess one way of asking is, for any two class
> objects (not instances) C1 and C2, does "C1 == C2" imply "C1 is C2"?

C and D are instances of metaC in that.

class metaC( type ):
def what( self ):
return self

class C( metaclass= metaC ): pass
class D( metaclass= metaC ): pass

assert C is C.what() and D is D.what()
#print( C.what(), D.what() )

C= metaC('C',(),{})
D= metaC('D',(),{})
assert C is C.what() and D is D.what()
#print( C.what(), D.what() )

furthermore.

Carl Banks

unread,
Mar 6, 2008, 9:30:41 AM3/6/08
to
On Mar 5, 8:44 pm, Steven D'Aprano <st...@REMOVE-THIS-

cybersource.com.au> wrote:
> But what about classes? Are they singletons? Obviously classes aren't
> Singleton classes, that is, given an arbitrary class C you can create
> multiple instances of C. But what about class objects themselves? I've
> found a few odd references to "classes are singletons", but nothing in
> the language reference.


Probably because "singleton" is the wrong word. A singleton means
there is one instance of a type; classes are instances of "type" which
can have many instances so classes are not singletons.

Anyway, the answer to what you are probably asking is No. Try this:

>>>import module
>>>c1 = module.Someclass
>>>reload(module)
>>>c2 = module.Someclass
>>>c1 is c2


For that matter, try this:

>>>import module
>>>c1 = module.Someclass
>>>module.Someclass = some_other_class()
>>>c2 = module.Someclass
>>>c1 is c2


Carl Banks

casti...@gmail.com

unread,
Mar 6, 2008, 2:06:50 PM3/6/08
to
On Mar 6, 8:30 am, Carl Banks <pavlovevide...@gmail.com> wrote:
> On Mar 5, 8:44 pm, Steven D'Aprano <st...@REMOVE-THIS-
>
> cybersource.com.au> wrote:
> > But what about classes? Are they singletons? Obviously classes aren't
> > Singleton classes, that is, given an arbitrary class C you can create
> > multiple instances of C. But what about class objects themselves? I've
> > found a few odd references to "classes are singletons", but nothing in
> > the language reference.
>
> Probably because "singleton" is the wrong word.  A singleton means
> there is one instance of a type; classes are instances of "type" which
> can have many instances so classes are not singletons.
>
> Anyway, the answer to what you are probably asking is No.  Try this:
>
> >>>import module
> >>>c1 = module.Someclass
> >>>reload(module)
> >>>c2 = module.Someclass
> >>>c1 is c2

What about

>>> o= object()
>>> b1= o.someattr
>>> reload( o )
>>> b2= o.someattr
>>> b1 is b2

?

Marc 'BlackJack' Rintsch

unread,
Mar 6, 2008, 3:57:46 PM3/6/08
to

You are really a bit thick, a troll, or a bot.

*plonk*

Ciao,
Marc 'BlackJack' Rintsch

Aahz

unread,
Mar 6, 2008, 4:24:47 PM3/6/08
to
In article <13sulsu...@corp.supernews.com>,

Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> wrote:
>
>I accept my question about classes being singletons is not well-formed,
>not even in my own mind. I guess one way of asking is, for any two class
>objects (not instances) C1 and C2, does "C1 == C2" imply "C1 is C2"?

Even that stricture fails under the presence of metaclasses. ;-) But
answering your real question, I don't remember off-hand the required
sequence, but it is possible to import a class two different ways such
that the classes are not the object. This can cause problems with e.g.
pickle. Within a single module, given a class defined only once within
that module, the class will be a singleton.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of
indirection." --Butler Lampson

casti...@gmail.com

unread,
Mar 6, 2008, 5:30:14 PM3/6/08
to

The point was, that's one difference between classes and modules: you
can't reload classes plonk.

casti...@gmail.com

unread,
Mar 6, 2008, 5:45:09 PM3/6/08
to
On Mar 6, 3:24 pm, a...@pythoncraft.com (Aahz) wrote:
> In article <13sulsu4nbr2...@corp.supernews.com>,

> Steven D'Aprano  <st...@REMOVE-THIS-cybersource.com.au> wrote:
>
>
>
> >I accept my question about classes being singletons is not well-formed,
> >not even in my own mind. I guess one way of asking is, for any two class
> >objects (not instances) C1 and C2, does "C1 == C2" imply "C1 is C2"?
>
> Even that stricture fails under the presence of metaclasses.  ;-)  But
> answering your real question, I don't remember off-hand the required
> sequence, but it is possible to import a class two different ways such
> that the classes are not the object.  This can cause problems with e.g.
> pickle.  Within a single module, given a class defined only once within
> that module, the class will be a singleton.
> --
> Aahz (a...@pythoncraft.com)           <*>        http://www.pythoncraft.com/

>
> "All problems in computer science can be solved by another level of    
> indirection."  --Butler Lampson

I'd like to question the source of the definition of C.__eq__.

Observation:

>>> class C: pass
...
>>> class D: pass
...
>>> C== D
False

What is different about them? I've created two empty classes, nothing
more.

Gabriel Genellina

unread,
Mar 6, 2008, 6:17:49 PM3/6/08
to pytho...@python.org
En Thu, 06 Mar 2008 20:45:09 -0200, <casti...@gmail.com> escribi�:

> I'd like to question the source of the definition of C.__eq__.
>
> Observation:
>
>>>> class C: pass
> ...
>>>> class D: pass
> ...
>>>> C== D
> False
>
> What is different about them? I've created two empty classes, nothing
> more.

Their __name__ attribute?
Types are compared by their memory addresses, not by contents, and that's
enough and efficient for most people. If you require something different,
use a metaclass.

--
Gabriel Genellina

Steven D'Aprano

unread,
Mar 7, 2008, 7:15:17 AM3/7/08
to
On Thu, 06 Mar 2008 06:30:41 -0800, Carl Banks wrote:

> On Mar 5, 8:44 pm, Steven D'Aprano <st...@REMOVE-THIS-
> cybersource.com.au> wrote:
>> But what about classes? Are they singletons? Obviously classes aren't
>> Singleton classes, that is, given an arbitrary class C you can create
>> multiple instances of C. But what about class objects themselves? I've
>> found a few odd references to "classes are singletons", but nothing in
>> the language reference.
>
>
> Probably because "singleton" is the wrong word. A singleton means there
> is one instance of a type; classes are instances of "type" which can
> have many instances so classes are not singletons.

Right. I knew there was something funny about using the term "singleton"
to refer to classes, but I couldn't put my finger on it.

[snip]

> For that matter, try this:
>
>>>>import module
>>>>c1 = module.Someclass
>>>>module.Someclass = some_other_class()
>>>>c2 = module.Someclass
>>>>c1 is c2

That example is cheating because you rebind the *name* module.Someclass.
Of course you get something different.

But in any case, I'm satisfied now... the name singleton is inappropriate
for modules and classes, although they are both singleton-like. I like
Gabriel's term "named singleton" (from another thread).

Thank you to everybody who answered.


--
Steven

0 new messages