Question about object lifetime and access

[Asaf Las]

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.