On Wed, Jan 15, 2014 at 11:13 PM, Asaf Las <roeg...@gmail.com> wrote: > Questions are: > - what is the lifetime for global object (p in this example). > - will the p always have value it got during module loading > - if new thread will be created will p be accessible to it > - if p is accessible to new thread will new thread initialize p value again? > - is it guaranteed to have valid p content (set to "module is loaded") > whenever application() function is called. > - under what condition p is cleaned by gc.
Your global p is actually exactly the same as the things you imported. In both cases, you have a module-level name bound to some object. So long as that name references that object, the object won't be garbage collected, and from anywhere in the module, you can reference that name and you'll get that object. (Unless you have a local that shadows it. I'll assume you're not doing that.) How do you go about creating threads? Is it after initializing the module? If so, they'll share the same p and the same object that it's pointing to - nothing will be reinitialized. As long as you don't change what's in p, it'll have the same value ([1] - handwave) whenever application() is called. That's a guarantee. For your lambda functions, you could simply make them module-level functions. You could then give them useful names, too. But decide based on code readability rather than questions of performance. At this stage, you have no idea what's going to be fast or slow - wait till you have a program that's not fast enough, and then *profile it* to find the slow bits. Unless you're doing that, you're completely wasting your time trying to make something faster. Start with readable, idiomatic code, code that you could come back to in six months and be confident of understanding. Do whatever it takes to ensure that, and let performance take care of itself. Nine times out of ten, you won't even have a problem. In the past twelve months, I can think of exactly *one* time when I needed to improve an app's performance after I'd coded it the readable way, and there was just one part of the code that needed to be tweaked. (And it was more of an algorithmic change than anything else, so it didn't much hurt readability.) Remember the two rules of code optimization: 1. Don't. 2. (For experts only) Don't yet. Follow those and you'll save more time than you would gain by micro-optimizing. And your time is worth more than the computer's. ChrisA [1] Technically p doesn't "have a value" at all. It's a name that's bound to some object. You can rebind it to another object, you can mutate the object it's bound to (except that you've bound it to a string, which is immutable), or you can sever the connection (with 'del p'), but in simple terms, it's generally "near enough" to say that p has a value. -- https://mail.python.org/mailman/listinfo/python-list