Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Brain Dead Singleton

Reply
Thread Tools

Brain Dead Singleton

 
 
Kamilche
Guest
Posts: n/a
 
      06-04-2004
I looked on this newsgroup, and saw all the problems with making a
Singleton class with Python.

I don't really care about 'returning the single shared instance' in
the constructor and all, I just want to avoid being inefficient... so
I implemented this (code fragment follows):

class Whatever:
_singleton = 0
def __init__(self):
self.__class__._singleton += 1
if self.__class__._singleton > 1:
raise Exception("Singleton!")

There. I've got it trussed up to where I can't create more than one
without raising an exception, which works good enough for my purposes.

--Kamilche
 
Reply With Quote
 
 
 
 
Colin Brown
Guest
Posts: n/a
 
      06-05-2004
"Kamilche" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> I looked on this newsgroup, and saw all the problems with making a
> Singleton class with Python.


Whenever I want a singleton "class", I just use a module with functions and
global variables. Modules only import once.

Colin Brown
PyNZ



 
Reply With Quote
 
 
 
 
Robin Becker
Guest
Posts: n/a
 
      06-05-2004
Colin Brown wrote:
> "Kamilche" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
>
>>I looked on this newsgroup, and saw all the problems with making a
>>Singleton class with Python.

>
>
> Whenever I want a singleton "class", I just use a module with functions and
> global variables. Modules only import once.
>
> Colin Brown
> PyNZ
>
>
>

should often work, but this illustrates how it can go wrong

##################
f=open('my_singleton_module.py','w')
f.write('''a=0
def incr(i):
global a
oa = a
a+=i
return oa
''')
f.close()

import my_singleton_module as inst0
print inst0.a
inst0.incr(5)
print inst0.a
import sys
del sys.modules['my_singleton_module']
import my_singleton_module as inst1
print inst1.a
##################

so if sys.modules gets interfered with approriately, your singleton can
start breeding.
--
Robin Becker
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      06-05-2004
Robin Becker wrote:

> Colin Brown wrote:
>> Whenever I want a singleton "class", I just use a module with
>> functions and
>> global variables. Modules only import once.
>>

> should often work, but this illustrates how it can go wrong

[...]
> del sys.modules['my_singleton_module']

[...]
> so if sys.modules gets interfered with approriately, your singleton can
> start breeding.


We're all adults. How often do you see (or write) code that
goes around deleting modules from sys.modules. Colin's
suggesting is just fine for most sane situations.

-Peter
 
Reply With Quote
 
Robin Becker
Guest
Posts: n/a
 
      06-05-2004
Peter Hansen wrote:

> Robin Becker wrote:
>
>> Colin Brown wrote:
>>
>>> Whenever I want a singleton "class", I just use a module with
>>> functions and
>>> global variables. Modules only import once.
>>>

>> should often work, but this illustrates how it can go wrong

>
> [...]
>
>> del sys.modules['my_singleton_module']

>
> [...]
>
>> so if sys.modules gets interfered with approriately, your singleton
>> can start breeding.

>
>
> We're all adults. How often do you see (or write) code that
> goes around deleting modules from sys.modules. Colin's
> suggesting is just fine for most sane situations.
>
> -Peter


well I actually have a use case for deleting modules from sys.modules.
In some legacy code for ReportLab documentation, import was used in the form

import chapter1
import chapter2
......

in two different documents causing confusion. An easy fix involved
restoring sys.modules to a pristine state before each document was
generated.
--
Robin Becker
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      06-06-2004
Robin Becker wrote:

> Peter Hansen wrote:
>> Colin's suggesting is just fine for most sane situations.

>
> well I actually have a use case for deleting modules from sys.modules.

[...]
> An easy fix involved restoring sys.modules to a pristine state
> before each document was generated.


I'd argue perhaps that "easy fix" should have read "hack", and
that this doesn't fit my condition of "most sane situations".

Would you say that this "fix" was really an elegant solution,
or just a quick hack? I don't think deleting things from
sys.modules has defined, guaranteed behaviour, so I'm uncertain
whether anyone should rely on it working. I still think
Colin's approach is a generally okay one.

-Peter
 
Reply With Quote
 
Robin Becker
Guest
Posts: n/a
 
      06-07-2004
Peter Hansen wrote:

.......

> > An easy fix involved restoring sys.modules to a pristine state
> > before each document was generated.

>
> I'd argue perhaps that "easy fix" should have read "hack", and
> that this doesn't fit my condition of "most sane situations".
>


I think I would agree that this is a hack. Probably the correct fix
would have been to packagize each document folder and the containing
folder and then change all the imports to be absolute, but that would
have meant changing far more lines of code and introducing packages
which are not really packages.

> Would you say that this "fix" was really an elegant solution,
> or just a quick hack? I don't think deleting things from
> sys.modules has defined, guaranteed behaviour, so I'm uncertain
> whether anyone should rely on it working. I still think
> Colin's approach is a generally okay one.
>
> -Peter


If sys.modules isn't intended to be a modifiable cache, perhaps we
shouldn't be given access to it.

The docs for 2.3 say
"modules
This is a dictionary that maps module names to modules which have
already been loaded. This can be manipulated to force reloading of
modules and other tricks. Note that removing a module from this
dictionary is not the same as calling reload() on the corresponding
module object."

So the Gods call call this a trick
--
Robin Becker
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      06-07-2004
Robin Becker wrote:
> Peter Hansen wrote:
>> I don't think deleting things from
>> sys.modules has defined, guaranteed behaviour, so I'm uncertain
>> whether anyone should rely on it working.

>
> If sys.modules isn't intended to be a modifiable cache, perhaps we
> shouldn't be given access to it.
>
> The docs for 2.3 say
> "modules
> This is a dictionary that maps module names to modules which have
> already been loaded. This can be manipulated to force reloading of
> modules and other tricks.... "


Hmmm... I'd be more inclined to think it was an approval
if it didn't use the term "trick" to describe it.

Anyway, this now leads me to wonder whether any singleton
pattern which doesn't involve manipulating __builtin__ is
safe from deletion of items in sys.modules...

-Peter
 
Reply With Quote
 
Robin Becker
Guest
Posts: n/a
 
      06-07-2004
Peter Hansen wrote:
.......
>> The docs for 2.3 say
>> "modules
>> This is a dictionary that maps module names to modules which have
>> already been loaded. This can be manipulated to force reloading of
>> modules and other tricks.... "

>
>
> Hmmm... I'd be more inclined to think it was an approval
> if it didn't use the term "trick" to describe it.
>
> Anyway, this now leads me to wonder whether any singleton
> pattern which doesn't involve manipulating __builtin__ is
> safe from deletion of items in sys.modules...


.....

If you hold onto an instance then I think it's safe, I guess the problem
is when the class code (from a module) gets violently changed in some
way. When you next get an instance even from a borg type pattern it
needn't be the same as the last instance. Of course modules, classes etc
are not normally read only so they can be subverted just by writing into
them.

> -Peter

--
Robin Becker
 
Reply With Quote
 
Kamilche
Guest
Posts: n/a
 
      06-08-2004
Well, to cop a phrase from 'Brother Where Art Thou?', "I'm with you
fellers."

You both are much more experienced than I, so much so that I don't
even know what you're talking about, yet.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
left brain and right brain permutations pataphor Python 0 06-14-2009 07:14 PM
Singleton object vs. enhancing singleton class Paul McMahon Ruby 3 06-09-2008 06:05 AM
Singleton Modules rather than Singleton Classes Trans Ruby 12 09-14-2007 06:45 AM
Singleton - Whether Cloneable overrides Singleton Proton Projects - Moin Java 4 03-27-2007 02:59 AM
Singleton classes and Singleton pattern Wilhelm Ruby 1 10-11-2006 01:08 PM



Advertisments