Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Assigning to self

Reply
Thread Tools

Assigning to self

 
 
John Roth
Guest
Posts: n/a
 
      01-17-2005

"Frans Englich" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Monday 17 January 2005 20:03, John Roth wrote:
>> "Frans Englich" <(E-Mail Removed)> wrote in message

>
> <snip>
>
>> In other words, you're trying to create a singleton. In general,
>> singletons are frowned on these days for a number of reasons,
>> not least because of the difficulty of testing them.

>
> Then I have some vague, general questions which perhaps someone can reason
> from: what is then the preferred methods for solving problems which
> requires
> Singletons? Is it only frowned upon in Python code?


I don't know of any generic methods that will work in all
cases _and_ are easy to apply. There are really two issues:
testing and abuse of the pattern.

There really are some places where you want a single instance
of something that is globally visible. Things that leap immediately
to mind include the connection to a data base and a logger
facility.

However, in a lot of cases, you find singletons used as an
"object oriented" substitute for a global variable, which stinks
just as badly as a global would. Since Python is a multi-paradigm
language, just put in a global at the module level. It's clearer.
Otherwise redesign.

There are several ways of getting around the testing
difficulty. One is the "toolbox" pattern that appears in a
number of places. The idea there is to have a single
object that proxies all of the singletons so that they
can be replace by testing versions at initialization time.

A neater and more modern method is to use an IOC
(Inversion of Control) container, or at least the pattern
involved. All IOC containers I'm aware of support
singletons and make testing them almost trivially
easy.

A third way is to simply take advantage of Python's
dynamic nature and have your tests stuff the testing
instance into the class object before the first call. This
is an ad-hoc variation on the IOC principle.

HTH

John Roth

>
>
> Cheers,
>
> Frans
>


 
Reply With Quote
 
 
 
 
Marc 'BlackJack' Rintsch
Guest
Posts: n/a
 
      01-18-2005
In <(E-Mail Removed)>, Frans Englich
wrote:

> Then I have some vague, general questions which perhaps someone can reason
> from: what is then the preferred methods for solving problems which requires
> Singletons?


As already mentioned it's similar to a global variable. If I need a
"Singleton" I just put it as global into a module. Either initialize it
at module level or define a function with the content of your __init__().

Ciao,
Marc 'BlackJack' Rintsch
 
Reply With Quote
 
 
 
 
Jeff Shannon
Guest
Posts: n/a
 
      01-18-2005
Marc 'BlackJack' Rintsch wrote:

> Frans Englich wrote:
>
>>Then I have some vague, general questions which perhaps someone can reason
>>from: what is then the preferred methods for solving problems which requires
>>Singletons?

>
> As already mentioned it's similar to a global variable. If I need a
> "Singleton" I just put it as global into a module. Either initialize it
> at module level or define a function with the content of your __init__().


If one is determined to both use a Singleton and avoid having a plain
module-global variable, one could (ab)use function default parameters:

class __Foo:
"I am a singleton!"
pass

def Foo(foo_obj = __Foo()):
assert isinstance(foo_obj, __Foo
return foo_obj

Of course, this suffers from the weakness that one might pass an
object as an argument to the factory function and thus temporarily
override the Singleton-ness of __Foo... but a determined programmer
will work around any sort of protection scheme anyhow.

In general, ISTM that if one wants a Singleton, it's best to create it
via a factory function (even if that function then masquerades as a
class). This gives you pretty good control over the circumstances in
which your Singleton will be created and/or retrieved, and it also
makes it trivial to replace the Singleton with some other pattern
(such as, e.g., a Flyweight or Borg object) should the need to
refactor arise.

Jeff Shannon
Technician/Programmer
Credit International


 
Reply With Quote
 
top
Guest
Posts: n/a
 
      02-12-2005
Jeff Shannon wrote:
> class __Foo:
> "I am a singleton!"
> pass
>
> def Foo(foo_obj = __Foo()):
> assert isinstance(foo_obj, __Foo
> return foo_obj

this is a bit simpler, I think, and takes advantage from Python's free
name-rebinding.

class Singleton(object):
def __call__(self):
return self
Singleton = Singleton()

And, now, every time you say obj = Singleton(), you're getting the same
instance. Of course, this corrupt the __call__ method of the class, and
isn't inheritance-safe at all, but if you want only one or two classes
like this, it isn't very much work to implement it. Also, it's free of
weird metaclasses, __new__s, or __dict__ hacks, I think.
Just putting my two-cents into this,
--
- Alexandre

 
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
Changing self: if self is a tree how to set to a different self Bart Kastermans Python 6 07-13-2008 11:19 AM
__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y;self.z=z boilerplate code) falcon Python 0 07-31-2005 05:41 PM
Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y;self.z=z boilerplate code) Ralf W. Grosse-Kunstleve Python 2 07-12-2005 03:20 AM
Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code Ralf W. Grosse-Kunstleve Python 16 07-11-2005 09:28 PM
__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y;self.z=z boilerplate code) Ralf W. Grosse-Kunstleve Python 18 07-11-2005 04:01 PM



Advertisments