Thanks! On Wednesday, January 15, 2014 3:05:43 PM UTC+2, Chris Angelico 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