__init__.py file executed twice ?
martvefun
I'd like to start some threads when the server launch to listen to
events (I'm doing message passing).
To do so, I guess I should be using the __init__.py file at the root of
my project (by the way, what's the used of the other __init__.py files
in the apps)
I've tried with a simple test by only having 'print "starting server"'
into the file and the result is :
$ python manage.py runserver
starting server
starting server
Validating models...
0 errors found
Django version 1.2.3, using settings 'website.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Why the file is executed twice ? I don't want to have twice the same
threads.
Thank you
mart
Tom Evans
__init__.py files aren't executed at the start of programs, the
presence of them denotes that a directory is a python module, and the
__init__.py is executed when that module is first imported under a
particular name.
Do you have a structure like this:
project
├── __init__.py
├── app1
│ └── __init__.py
└── app2
├── __init__.py
└── models.py
and import from project.app2.models and from app2.models? That would
cause app2's __init__.py to be executed twice.
Cheers
Tom
martvefun
Yes the structure of my project is more or less like that but I've not
two but 6 apps all with 'from django.db import models' in models.py
In several model (more than two), I'm using foreign keys to different
models.
For now the site doesn't do much, I'm using the database created with
the models in other files in the project folder.
So if the __init__.py is not a good place to start operations at server
startup, where should I put it ?
Mike Dewhirst
>> ├── app1
>> │ └── __init__.py
>> └── app2
>> ├── __init__.py
>> └── models.py
>>
>> and import from project.app2.models and from app2.models? That would
>> cause app2's __init__.py to be executed twice.
>>
>> Cheers
>>
>> Tom
>>
>
> Yes the structure of my project is more or less like that but I've not
> two but 6 apps all with 'from django.db import models' in models.py
> In several model (more than two), I'm using foreign keys to different
> models.
> For now the site doesn't do much, I'm using the database created with
> the models in other files in the project folder.
>
> So if the __init__.py is not a good place to start operations at server
> startup, where should I put it ?
It seems like a good place to put it. Maybe you can test to see if the
threads have been started already?
Here is a singleton which could live in your __init__.py and might help
to record the state of your threading ... or anything else for that matter.
class singleton(object):
""" designed by Oren Tirosh and Jeff Pitman """
def __new__(self, *args, **kwargs):
if not '_singleton' in self.__dict__:
slate = object.__new__(self)
slate.state = {
'threads':True,
# add other state things as required
}
self._singleton = slate
return self._singleton
hth
Mike
>
martvefun
> It seems like a good place to put it. Maybe you can test to see if the
> threads have been started already?
>
> Here is a singleton which could live in your __init__.py and might
> help to record the state of your threading ... or anything else for
> that matter.
>
> class singleton(object):
> """ designed by Oren Tirosh and Jeff Pitman """
> def __new__(self, *args, **kwargs):
> if not '_singleton' in self.__dict__:
> slate = object.__new__(self)
> slate.state = {
> 'threads':True,
> # add other state things as required
> }
> self._singleton = slate
> return self._singleton
>
> hth
>
> Mike
>
In my case, I create several objects like this :
# __init__.py
profile_rec_port = ProfileRecorder()
evaluation_port = EvaluationManager()
...
# evaluationmanager.py
class EvaluationManager(Thread):
def __init__(self):
self.port = Queue() # Initialize an infinite empty queue
Thread.__init__(self) # Initialze the thread
self.start() # Launch the thread
...
Mike Dewhirst
> On 09-12-10 01:37, Mike Dewhirst wrote:
>> It seems like a good place to put it. Maybe you can test to see if the
>> threads have been started already?
>>
>> Here is a singleton which could live in your __init__.py and might
>> help to record the state of your threading ... or anything else for
>> that matter.
>>
>> class singleton(object):
>> """ designed by Oren Tirosh and Jeff Pitman """
>> def __new__(self, *args, **kwargs):
>> if not '_singleton' in self.__dict__:
>> slate = object.__new__(self)
>> slate.state = {
>> 'threads':True,
>> # add other state things as required
>> }
>> self._singleton = slate
>> return self._singleton
>>
>> hth
>>
>> Mike
>>
> Sorry but I don't really understand how works the function you gave me.
A singleton is a class which guarantees to return exactly the same
object every time. It can only create an object once then returns a
handle to the existing object instead of creating a new one.
If you initiate your threads and set (in the above example)
slate.state['threads'] = True I think you can rely on that and avoid
initiating them twice.
I used it once to manage the state of a "switch" where different parts
of the project could instantiate a singleton object and read the state,
make decisions and update the state reliably for other part of the app.
Mike
martvefun
Thank you, it works if I have to call in the same files (like s1 =
singleton() ; s2 = singleton() ) but here I still have two calls
class singleton(object):
""" designed by Oren Tirosh and Jeff Pitman """
def __new__(self, *args, **kwargs):
print "call singleton"
if not '_singleton' in self.__dict__:
print "first time created"
slate = object.__new__(self)
slate.state = {
'threads':True,
# add other state things as required
}
self._singleton = slate
return self._singleton
singleton()
print "Server is now runing"
gives me :
$ python manage.py runserver
call singleton
first time created
Server is now runing
call singleton
first time created
Server is now runing
Validating models...
0 errors found
And anyway I just realised another problem : I'll need to have access to
the objects I created from views.
The idea is to send a message to the thread when a certain action is
done (like user registration, validate choices...) but to do that I need
an access to this object (I cannot create another one because of
concurrency safety)
Any idea ?
Mike Dewhirst
> On 10-12-10 11:09, Mike Dewhirst wrote:
> > On 10/12/2010 7:43pm, martvefun wrote:
> >> On 09-12-10 01:37, Mike Dewhirst wrote:
> >>> It seems like a good place to put it. Maybe you can test to see if the
> >>> threads have been started already?
does return exactly the same object each time - manage.py runserver
apparently starts the framework twice. Hence you see it twice. I
noticed that when you edit a file and the dev server automatically
restarts, the singleton gets recreated but only once as expected.
Here is some research by Graham Dumpleton earlier this year and which
explains the process in detail ...
http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
If you decide to use a singleton to monitor state you might have to
look for somewhere safe to start it.
>
> And anyway I just realised another problem : I'll need to have access to
> the objects I created from views.
to test it.
Mike
Brian Bouterse
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
--
Brian Bouterse
ITng Services
mart
With the mod_wsgi and apache where can I see the results of my "print" ?