Overriding a global

[Jean-Michel Pichavant]

Joshua Landau wrote:
> [snip]
> Using currentLogger is just padding, in my opinion. *Every *value is 
> "current<value>".
Not always. I try to keep names on the same object because that object 
is supposed to be named that way.
I can change one of the object attribute, but the object named that way 
keep being the same.

Class Foo:
  self.__init__(self):
     self.banana = 5

myFoo = Foo()

Now there's a slight difference between

myFoo = Exception()
and
myFoo.banana = 4

The first statement rebind myFoo to something complitely different.
the second statement change one of the object rightfully named myFoo .. 
attribute (not sure about this construct :D )

Int being inmutable, you can rebind a name without changing its meaning.

>
> In regards to a second name - yes this could work and in many cases 
> would be desirable, but it doesn't really help this circumstance. 
> [assume, for a moment, a lot of functions used a local logger] 
> "localLogger" would tell you very little about what the logger 
> actually /is/. You still have to look that up. [end assumption] 
> Additionally, this would make changing a logger that uses the default 
> to a local one /much/ harder. And don't say "but you can just always 
> make a local copy", as then you lose the advantage of a global.
>
> Typing something like "logger = childLogger(id)" to the start of a 
> function call *is explicit*, it's clean, and it makes sense to have a 
> default that's global. You're not appending cruft ("current") and you 
> have consistency. If you added "logger = globalLogger" to every 
> function start as well you can argue that it's better. I agree it's 
> more explicit. But then you lose unneeded if only a small portion of 
> your code localises logger. But I would recommend it if a large 
> portion of code used local variants.
>
> AND:
>
>     The next time I'll illustrate meaningful names,  I'll write a 3000
>     lines function, just to be sure no one states that my point
>     does'nt apply to a function named spam which only counts from 1 to 3.
>     And don't answer that the spam function above does not count from
>     1 to 3, I know it doesn't.
>
>
> You're acting in sarcasm to a comment on scale, when you yourself said 
> that one of my comments was invalid due to names that were scaled down 
> for exampling. It seems a bit hypocritical to me. That said, not all 
> functions are long. If the short ones use short names that's fine: I'm 
> pretty sure you said it's not.
>
> And in regards to the link:
> 1) __add__ says otherwise (technically, the operator "+"). It's rarely 
> confused me.
> 2) That's not what we're discussing. As it said: "As long as the 
> parameter lists are semantically equal and the desired result is the 
> same, all is well." They're doing semantically the same thing (to 
> different log levels) with the same parameter lists and they're not 
> class methods. You /could/ say that the semantics are different, but 
> classes act in a context in the same way local variables can be 
> thought of doing, and semantics are the same for them. Instead of a 
> different self, it's a different log file/level. Same semantics.
I'd like to argue about that but I won't cause I have the feeling my 
lack of ultra precise english would cause me more trouble. Note that I'm 
not blaming anyone but me, no sarcasm inside.

JM