On 7/6/06, Iain Duncan <[EMAIL PROTECTED]> wrote: > > > > Code in the global namespace is executed at module import time. > > These variables live as long as the python interpreter runs. (at least > > thats my understanding of it) > > > > This is great for constants and such, but you can't rely on it to store > > state variables as, depending on the environment/server you run python > > on, you have no or little control of how or when the interpreter is > > restarted. > > > > With mod_python on *NIX for example, you have multiple apache processes > > each with it's own python interpreter. An apache process serves n > > requests, then it's killed and a new one is started. Subsequent requests > > from one client will not necessarily be served by the same apache process. > > > > So no, it's not safe to store important data there. It's better to use a > > session, database, or file based solution. > > Thanks for the explanation. Does that mean that objects created in the > global namespace are shared between seperate client hits on the app too? > Specifically I'm wondering how this will affect the best way to use > singleton objects.
Separate client hits might hit separate Python interpreter instances, and each of those instances will have imported the global namespace on their own, creating separate global namespaces. So like Steven said, it's not safe to do anything in the global namespace. If you need a per-session singleton, you can store it in request.session. If you need a per-application singleton, then you're going to have trouble... Jay P. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
