Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #34493 > unrolled thread

Help with Singleton SafeConfigParser

Started byJosh English <Joshua.R.English@gmail.com>
First post2012-12-08 09:11 -0800
Last post2012-12-08 09:48 -0800
Articles 5 — 3 participants

Back to article view | Back to comp.lang.python


Contents

  Help with Singleton SafeConfigParser Josh English <Joshua.R.English@gmail.com> - 2012-12-08 09:11 -0800
    Re: Help with Singleton SafeConfigParser Peter Otten <__peter__@web.de> - 2012-12-08 18:40 +0100
      Re: Help with Singleton SafeConfigParser Josh English <Joshua.R.English@gmail.com> - 2012-12-08 09:48 -0800
        Re: Help with Singleton SafeConfigParser Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-12-08 20:23 +0000
      Re: Help with Singleton SafeConfigParser Josh English <Joshua.R.English@gmail.com> - 2012-12-08 09:48 -0800

#34493 — Help with Singleton SafeConfigParser

FromJosh English <Joshua.R.English@gmail.com>
Date2012-12-08 09:11 -0800
SubjectHelp with Singleton SafeConfigParser
Message-ID<113bded6-c75f-4322-9703-93420b4c3522@googlegroups.com>
I am trying to create a Singleton SafeConfigParser object to use across all the various scripts in this application. 

I tried a Singleton pattern found on the web:

<pre>
class Singleton(object):
    def __new__(cls):
        if not hasattr(cls, '_inst'):
            print "Creating Singleton Object"
            cls._inst = super(Singleton, cls).__new__(cls)
        else:
            print "Returning established Singleton"

        return cls._inst

import ConfigParser

class Options(ConfigParser.SafeConfigParser, Singleton):
    def __init__(self):
        print "Initialing Options"
        ConfigParser.SafeConfigParser.__init__(self)
        self.add_section('test')
</pre>

And this doesn't work because it calls the __init__ method every time I create the Options object:

<pre>

O = Options()
print O
O.set('test','start','True')
print "from O", O.options('test')


P = Options()
print P
print "from P", P.options('test')
</pre>

This results in:

<pre>
Creating Singleton Object
Initialing Options
<__main__.Options object at 0x02BF4C50>
from O ['start']
Returning established Singleton
Initialing Options
<__main__.Options object at 0x02BF4C50>
from P []
</pre>


I have seen older posts in this group that talk about using modules as singletons, but this, unless I misunderstand, requires me to code the entire API for SafeConfigParser in the module:

<pre>
import ConfigParser


class Options(ConfigParser.SafeConfigParser):
    def __init__(self):
        ConfigParser.SafeConfigParser.__init__(self)
        self.readfp(open('defaults.cfg'))
        self.read(['local.txt', 'local.cfg'])

    def save(self):
        with open('local.txt','w') as f:
            self.write(f)

__options = Options()

def set(section, name, value):
    return self.__options.set(section, name, value)

def options(section):
    return self.__options.options

# And so on
</pre>

This seems incredibly wasteful, and to introspect my options I get a module, not a SafeConfigParser object, so I'm wondering if there is a different way to handle this?

Josh

[toc] | [next] | [standalone]


#34494

FromPeter Otten <__peter__@web.de>
Date2012-12-08 18:40 +0100
Message-ID<mailman.625.1354988369.29569.python-list@python.org>
In reply to#34493
Josh English wrote:

> I have seen older posts in this group that talk about using modules as 
singletons, but this, unless I misunderstand, requires me to code the entire 
API for SafeConfigParser in the module:
> 
> <pre>
> import ConfigParser
> 
> 
> class Options(ConfigParser.SafeConfigParser):
>     def __init__(self):
>         ConfigParser.SafeConfigParser.__init__(self)
>         self.readfp(open('defaults.cfg'))
>         self.read(['local.txt', 'local.cfg'])
> 
>     def save(self):
>         with open('local.txt','w') as f:
>             self.write(f)
> 
> __options = Options()
> 
> def set(section, name, value):
>     return self.__options.set(section, name, value)
> 
> def options(section):
>     return self.__options.options
> 
> # And so on
> </pre>
> 
> This seems incredibly wasteful, and to introspect my options I get a 
module, not a SafeConfigParser object, so I'm wondering if there is a 
different way to handle this?

Two underscores trigger name mangling only in a class, not in a module. 
Don't try to hide the Options instance:

# module config.py
import ConfigParser

class Options(ConfigParser.SafeConfigParser):
     ... # as above

options = Options()

Then use it elsewhere:

from config import options

options.set("mysection", "myoption", "myvalue")

All but the first import will find the module in the cache (sys.modules) and 
therefore the same Options instance will be used. Voilà your no-nonsense 
singleton.

[toc] | [prev] | [next] | [standalone]


#34495

FromJosh English <Joshua.R.English@gmail.com>
Date2012-12-08 09:48 -0800
Message-ID<e33d91bc-cb8f-4414-9f8c-1339cecfc6f5@googlegroups.com>
In reply to#34494
On Saturday, December 8, 2012 9:40:07 AM UTC-8, Peter Otten wrote:
> 
> 
> 
> Two underscores trigger name mangling only in a class, not in a module. 
> 
> Don't try to hide the Options instance:
> 
> 
> 
> # module config.py
> 
> import ConfigParser
> 
> 
> 
> class Options(ConfigParser.SafeConfigParser):
> 
>      ... # as above
> 
> 
> 
> options = Options()
> 
> 
> 
> Then use it elsewhere:
> 
> from config import options
> 
> options.set("mysection", "myoption", "myvalue")
> 
> 
> 
> All but the first import will find the module in the cache (sys.modules) and 
> 
> therefore the same Options instance will be used. Voilà your no-nonsense 
> 
> singleton.


Ah. I was over-thinking again. I couldn't find an example of this anywhere, and when I saw the tirades against Singletons they mentioned "use modules" but, well, I haven't had my morning coffee yet. I shouldn't even be trying this sort of thing until then.

Thank you for the simple answer.

Josh

[toc] | [prev] | [next] | [standalone]


#34502

FromMark Lawrence <breamoreboy@yahoo.co.uk>
Date2012-12-08 20:23 +0000
Message-ID<mailman.630.1354998232.29569.python-list@python.org>
In reply to#34495
On 08/12/2012 17:48, Josh English wrote:
> On Saturday, December 8, 2012 9:40:07 AM UTC-8, Peter Otten wrote:
>>
>> Two underscores trigger name mangling only in a class, not in a module.
>>
>> Don't try to hide the Options instance:
>>
>> # module config.py
>>
>> import ConfigParser
>>
>> class Options(ConfigParser.SafeConfigParser):
>>
>>       ... # as above
>>
>> options = Options()
>>
>> Then use it elsewhere:
>>
>> from config import options
>>
>> options.set("mysection", "myoption", "myvalue")
>>
>> All but the first import will find the module in the cache (sys.modules) and
>>
>> therefore the same Options instance will be used. Voilà your no-nonsense
>>
>> singleton.
>
>
> Ah. I was over-thinking again. I couldn't find an example of this anywhere, and when I saw the tirades against Singletons they mentioned "use modules" but, well, I haven't had my morning coffee yet. I shouldn't even be trying this sort of thing until then.
>
> Thank you for the simple answer.
>
> Josh
>

For the benefit of the OP and others, if you want to gain more knowledge 
about patterns in Python such as the Singleton, I suggest you use your 
favourite search engine to find "Alex Martelli Python patterns".

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]


#34496

FromJosh English <Joshua.R.English@gmail.com>
Date2012-12-08 09:48 -0800
Message-ID<mailman.626.1354988895.29569.python-list@python.org>
In reply to#34494
On Saturday, December 8, 2012 9:40:07 AM UTC-8, Peter Otten wrote:
> 
> 
> 
> Two underscores trigger name mangling only in a class, not in a module. 
> 
> Don't try to hide the Options instance:
> 
> 
> 
> # module config.py
> 
> import ConfigParser
> 
> 
> 
> class Options(ConfigParser.SafeConfigParser):
> 
>      ... # as above
> 
> 
> 
> options = Options()
> 
> 
> 
> Then use it elsewhere:
> 
> from config import options
> 
> options.set("mysection", "myoption", "myvalue")
> 
> 
> 
> All but the first import will find the module in the cache (sys.modules) and 
> 
> therefore the same Options instance will be used. Voilà your no-nonsense 
> 
> singleton.


Ah. I was over-thinking again. I couldn't find an example of this anywhere, and when I saw the tirades against Singletons they mentioned "use modules" but, well, I haven't had my morning coffee yet. I shouldn't even be trying this sort of thing until then.

Thank you for the simple answer.

Josh

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web