Makes sense - thank you Eric
M
On 23/06/2018 5:10 PM, PASCUAL Eric wrote:
IMHO, some of (a lot of ?) the "classical" GOF patterns do not really
apply to Python (or at least are not necessary, when not making things
more confuse). They are often a consequence of constraints and
limitations of statically compiled languages such as C++, Java and
alike used at the time they have been created, but they loose most of
their interest for languages such as Python.
If the singleton instance is used internally by your application code,
and apart if you have really good reasons for making things more
complicated, juts use a module level variable to store the instance,
and initialize it at application start. Of course, forbid yourself to
write to this variable from elsewhere than the app initialization code.
If the singleton creation can be called from other places (f.i. if a
lazy initialization strategy is used), and if there are possibilities
for it to be called several times, a guard can be implemented by
providing a factory function which will test if the instance is
currently None, instantiate one if needed, store it in the module
variable, and return the module variable at the end. It would look
like this:
_singleton_instance = None
def get_singleton():
if _singleton_instanceis None:
_singleton_instance= ....
return _singleton_instance
The '_' prefix of the singleton variable is use to indicate that this
is a "private" variable which must not be referred to (even in read
access) from outside the module.
Hope this helps.
Regards
Eric
------------------------------------------------------------------------
*From:* django-users@googlegroups.com <django-users@googlegroups.com>
on behalf of Mike Dewhirst <mi...@dewhirst.com.au>
*Sent:* Saturday, June 23, 2018 2:01:06 AM
*To:* django-users@googlegroups.com
*Subject:* Re: prevent AppConfig.ready() from running twice
Is there a python singleton pattern which might work?
/Connected by Motorola/
Melvyn Sopacua <m.r.sopa...@gmail.com> wrote:
On donderdag 21 juni 2018 16:23:23 CEST clavierpla...@gmail.com wrote:
> If it helps, here is the reason I need to override this
multi-instantiation
> behavior: my application launches a multiprocessing.Process at
startup to
> monitor and run background tasks. Having more than one background
Process
> running at once is going to wreak havoc on the application. I've
looked at
> other options to accomplish similar purposes, but those would all be
> instantiated multiple times, also.
>
> Any suggestions?
Use a locked pidfile to prevent multiple daemons starting up. I recall
the
python-daemon package being capable of this (and lots of other good
stuff).
https://pagure.io/python-daemon/
--
Melvyn Sopacua
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/139066525.eYAS18T7Ez%40fritzbook.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/wb0bbtt2xa79lb1b10sny7md.1529712066075%40email.android.com
<https://groups.google.com/d/msgid/django-users/wb0bbtt2xa79lb1b10sny7md.1529712066075%40email.android.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/DB7P193MB0331E4C4C900D305CF7AA1308C740%40DB7P193MB0331.EURP193.PROD.OUTLOOK.COM
<https://groups.google.com/d/msgid/django-users/DB7P193MB0331E4C4C900D305CF7AA1308C740%40DB7P193MB0331.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/fc13cd81-9a73-04f8-0c9f-718ef53239ca%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
