[CentralOH] Another Revision of Singleton

[John Santiago]

I will read the links. Thank You!

I wanted to create a web application management tool for myself. Something
similar to Tomcat using CherryPy.  The main application 'Brigh' is the hub,
so I wanted to make it a singleton. It would have basic methods like app
creation and server methods. it would also be the main web-application.

Every-time I create a new application it will grab .zip /rar file, store
basic data to db and then create a physical location on the server. I will
also be using the host api to create domains then store domains in db ->
cherrypy virtualhost.

I only wanted to make the main application a singleton to make sure there
could not be more than one. Going to dive into the alex.it link now, but
what do you think?


On Mon, Mar 18, 2013 at 7:13 AM, Eric Floehr <eric at intellovations.com>wrote:

> John,
>
> In most cases where you think you need a Singleton design pattern, what
> you are really looking for is shared state. It doesn't matter how many
> class instances you have, so long as each of those instances share state.
>
> The problem many people have coming to Python from say C++, Java, C# and
> other class-oriented languages is that in those languages you can't easily
> separate the class instance from its state. In Python, being *object*
> oriented and not *class* oriented, it's easy. Another thing that tripped me
> up, coming from Java, is thinking of a module as just a namespace and not
> as an object as well.
>
> With that said, there are two alternatives to the Singleton object that
> may work better for you in Python than the implementation you'd
> found/developed. At the very least, understanding them will help you
> understand Python a little more.
>
> The first is the multi-instance/shared-state pattern, which Alex Martelli
> calls the "Borg Pattern". It's called the Borg pattern for obvious
> reasons... like the Borg, there are many instances but all share the same
> state :-). Alex's "Five Easy Pieces" post is a must read:
> http://www.aleax.it/5ep.html
>
> The second is that like everything in Python, a module is an object, not
> just a namespace. In fact, a module can be thought of as a singleton... it
> can have global state, has only once instance, and is an object. Here is a
> stackoverflow explanation... there is probably a better description
> somewhere but I can't find it in my bookmarks right now:
> http://stackoverflow.com/questions/10936709/why-does-a-python-module-act-like-a-singleton
>
> BUT...
>
> I would take a step back even further and ask yourself if you really even
> need a singleton. In most cases, you really don't, and you can make your
> program better by eliminating them. Google even wrote a singleton detector
> for its Java code:
> http://code.google.com/p/google-singleton-detector/wiki/WhySingletonsAreControversial
>
> I can't tell you if your design would be better without a singleton
> without knowing more about the use case. But at least read up on the Borg
> pattern and on modules as singletons and you will at least have a better
> understanding of Python.
>
> Cheers,
> Eric
>
>
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> http://mail.python.org/mailman/listinfo/centraloh
>
>


-- 
This electronic message is intended to be for the use only of the named
recipient, and may contain information that is confidential or privileged.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or use of the contents of this message is
strictly prohibited.  If you have received this message in error or are not
the named recipient, please notify us immediately by contacting the sender
at the electronic mail address noted above, and delete and destroy all
copies of this message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/centraloh/attachments/20130318/57deb135/attachment.html>