Re: Code exectution and persistent object question
>>Ok, so we're would be smart place to do housekeeping you want to have >>happen no matter what page is loaded? > > > Middleware: http://www.djangoproject.com/documentation/middleware/ > > You can have functions that run prior to a request being passed along, > prior to a view function being called, after an exception and/or after a > response has been created, with full access to the request and response. Thanks Malcolm. Guess that's what I'll read next! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Code exectution and persistent object question
On Thu, 2006-07-06 at 02:02 -0700, Iain Duncan wrote: > > 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... > > > > Ok, so we're would be smart place to do housekeeping you want to have > happen no matter what page is loaded? Middleware: http://www.djangoproject.com/documentation/middleware/ You can have functions that run prior to a request being passed along, prior to a view function being called, after an exception and/or after a response has been created, with full access to the request and response. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Code exectution and persistent object question
> 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... > Ok, so we're would be smart place to do housekeeping you want to have happen no matter what page is loaded? Perhaps store all the housekeeping in a per session singleton and start every view method with a call to it? Thanks guys Iain --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Code exectution and persistent object question
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 -~--~~~~--~~--~--~---
Re: Code exectution and persistent object question
> 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. Thanks Iain --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Code exectution and persistent object question
On 07/05/06 03:34, Iain Duncan wrote: > I stumbled on some behaviour that I'm sure is explained somewhere but > not in the tutorials so I haven't found it. > > I made a global log object for debugging. I noticed instantiating > objects in the view global name space executes before anything else in > the views module on page load, very useful for global containers or > loggers. I also noticed that on subsequent page loads, this code does > NOT get re-executed, and the state of member variables in the global > object are preserved. > > Questions: how is this accomplished? Are global objects serialized > behind the scenes in a session indexed table, and if so which one? > Is this behaviour safe to *rely* on for preserving state in an ongoing > session? IE could you safely implement a shopping cart that way? Seems > like very useful default behaviour. > 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. > Suggestion, maybe there should be a mention of this in the views > tutorial? Or was there one and I've been cramming this all in to my head > so fast it bled out the other end? ;) > > Loving it all so far! > Iain > ( And my tendons are sooo happy not to be reaching for [EMAIL PROTECTED]> all > the time! ) > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Code exectution and persistent object question
I stumbled on some behaviour that I'm sure is explained somewhere but not in the tutorials so I haven't found it. I made a global log object for debugging. I noticed instantiating objects in the view global name space executes before anything else in the views module on page load, very useful for global containers or loggers. I also noticed that on subsequent page loads, this code does NOT get re-executed, and the state of member variables in the global object are preserved. Questions: how is this accomplished? Are global objects serialized behind the scenes in a session indexed table, and if so which one? Is this behaviour safe to *rely* on for preserving state in an ongoing session? IE could you safely implement a shopping cart that way? Seems like very useful default behaviour. Suggestion, maybe there should be a mention of this in the views tutorial? Or was there one and I've been cramming this all in to my head so fast it bled out the other end? ;) Loving it all so far! Iain ( And my tendons are sooo happy not to be reaching for [EMAIL PROTECTED]> all the time! ) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
