On 14 December 2011 17:06, Jean-Michel Pichavant wrote:
> Joshua Landau wrote:
>
>> [snip]
>> Using currentLogger is just padding, in my opinion. *Every *value is
>> "current".
>>
> Not always. I try to keep names on the same object because that object is
> supposed to be named that way.
> I can c
Joshua Landau wrote:
[snip]
Using currentLogger is just padding, in my opinion. *Every *value is
"current".
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 bein
On 14 December 2011 10:14, Jean-Michel Pichavant wrote:
> Joshua Landau wrote:
>
> On 13 December 2011 13:30, Jean-Michel Pichavant
> > jeanmic...@sequans.com**>> wrote:
>>
>>writing
>>
>>x = 1
>>
>>def spam():
>> x = 2
>>
>>is in general a bad idea. That was my point.
>>
>>
Steven D'Aprano wrote:
On Wed, 14 Dec 2011 13:05:19 +0100, Jean-Michel Pichavant wrote:
Bad ideas :
i = 5
def spam():
for i,v in enumerate([1,2,3,4]):
for i,v in enumerate(['a','b', 'c']):
print i, v
print i,v # bad surprise
The bad surprise happens because you are u
On Wed, 14 Dec 2011 13:05:19 +0100, Jean-Michel Pichavant wrote:
> Bad ideas :
>
> i = 5
>
> def spam():
> for i,v in enumerate([1,2,3,4]):
> for i,v in enumerate(['a','b', 'c']):
> print i, v
> print i,v # bad surprise
The bad surprise happens because you are using the same nam
On Wed, Dec 14, 2011 at 11:05 PM, Jean-Michel Pichavant
wrote:
> Chris Angelico wrote:
>>
>> So... it's a bad idea for me to use 'i' many times in my code, with
>> the same name having different meanings in different places? In
>> languages with infinitely-nesting scopes...
> Bad ideas :
>
> i =
Chris Angelico wrote:
On Wed, Dec 14, 2011 at 9:14 PM, Jean-Michel Pichavant
wrote:
The problem makes little sense when using names like x or func1. Besides
namespace issues, naming 2 *different objects* with the same meaningful name
is usually a bad idea and points the fact that your names
On Wed, Dec 14, 2011 at 9:14 PM, Jean-Michel Pichavant
wrote:
> The problem makes little sense when using names like x or func1. Besides
> namespace issues, naming 2 *different objects* with the same meaningful name
> is usually a bad idea and points the fact that your names are no that
> meaningf
Joshua Landau wrote:
On 13 December 2011 13:30, Jean-Michel Pichavant
mailto:jeanmic...@sequans.com>> wrote:
writing
x = 1
def spam():
x = 2
is in general a bad idea. That was my point.
Why? I have a few (probably wrong) guesses.
Because you expect it to be the same
On 13 December 2011 19:54, Ian Kelly wrote:
> On Tue, Dec 13, 2011 at 12:43 PM, Joshua Landau
> wrote:
> > On 13 December 2011 19:34, Ian Kelly wrote:
> >>
> >> On Tue, Dec 13, 2011 at 1:34 AM, Joshua Landau
> >> wrote:
> >> >> No, there is another difference, the reason for rebinding the name
On Tue, Dec 13, 2011 at 12:43 PM, Joshua Landau
wrote:
> On 13 December 2011 19:34, Ian Kelly wrote:
>>
>> On Tue, Dec 13, 2011 at 1:34 AM, Joshua Landau
>> wrote:
>> >> No, there is another difference, the reason for rebinding the name.
>> >> In a subclass, you would rebind a class attribute be
On 13 December 2011 19:34, Ian Kelly wrote:
> On Tue, Dec 13, 2011 at 1:34 AM, Joshua Landau
> wrote:
> >> No, there is another difference, the reason for rebinding the name.
> >> In a subclass, you would rebind a class attribute because that
> >> particular attribute, which you need to change,
On Tue, Dec 13, 2011 at 1:34 AM, Joshua Landau
wrote:
>> No, there is another difference, the reason for rebinding the name.
>> In a subclass, you would rebind a class attribute because that
>> particular attribute, which you need to change, is used and expected
>> by external code, either in the
On 13 December 2011 13:30, Jean-Michel Pichavant wrote:
>
> writing
>
> x = 1
>
> def spam():
> x = 2
>
> is in general a bad idea. That was my point.
Why? I have a few (probably wrong) guesses.
Because you expect it to be the same every time you use it?
Well, then this should be "in general a
Steven D'Aprano wrote:
On Tue, 13 Dec 2011 10:54:51 +0100, Jean-Michel Pichavant wrote:
Steven D'Aprano wrote:
On Mon, 12 Dec 2011 12:13:33 +0100, Jean-Michel Pichavant wrote:
Using the same name for 2 different objects is a bad idea in general.
We have na
On Tue, 13 Dec 2011 10:54:51 +0100, Jean-Michel Pichavant wrote:
> Steven D'Aprano wrote:
>> On Mon, 12 Dec 2011 12:13:33 +0100, Jean-Michel Pichavant wrote:
>>
>>
>>> Using the same name for 2 different objects is a bad idea in general.
>>>
>>>
>> We have namespaces precisely so you don
Steven D'Aprano wrote:
On Mon, 12 Dec 2011 12:13:33 +0100, Jean-Michel Pichavant wrote:
Using the same name for 2 different objects is a bad idea in general.
We have namespaces precisely so you don't need to care about making names
globally unique.
I don't get your point, name
On 12/10/2011 09:47 PM, Roy Smith wrote:
I've got a code pattern I use a lot. In each module, I create a logger
for the entire module and log to it all over:
logger = logging.getLogger('my.module.name')
class Foo:
def function(self):
logger.debug('stuff')
logger.debug('other
On 13/12/2011, Ian Kelly wrote:
> On Mon, Dec 12, 2011 at 4:48 PM, Joshua Landau
> wrote:
>> Rebinding logger locally in a function is really no
>> different to a subclass rebinding a variable from its main class using
>> that
>> class' value. The only difference is that, in that case, you have a
On Mon, Dec 12, 2011 at 4:48 PM, Joshua Landau
wrote:
> Rebinding logger locally in a function is really no
> different to a subclass rebinding a variable from its main class using that
> class' value. The only difference is that, in that case, you have an
> alternate binding to the original value
On Tue, 13 Dec 2011 09:27:09 +1100, Ben Finney wrote:
> Dave Angel writes:
>
>> True, but in this code, the function is trying to both use the global
>> value, but also a local that deliberately has the same name, but a
>> different meaning and "value". The CPython compiler doesn't make this
>>
On 12/12/2011 06:48 PM, Joshua Landau wrote:
If a function knows of the presence of a global, it's not asking too
much for it to not re-use the same name in local scope.
Yes.
It's just a function wanting to act as-if it were in a different
environment than its default. By that same reasoning y
>
> > If a function knows of the presence of a global, it's not asking too
> > much for it to not re-use the same name in local scope.
>
> Yes.
It's just a function wanting to act as-if it were in a different
environment than its default. By that same reasoning you could state that
"If a function
Dave Angel writes:
> True, but in this code, the function is trying to both use the global
> value, but also a local that deliberately has the same name, but a
> different meaning and "value". The CPython compiler doesn't make this
> easy, and I think the globals() technique is unnecessarily obsc
Wouldn't this be nicer, though?:
def getChildLogger(id):
return logger.getChild(id)
def someFunc():
logger = getChildLogger("someFunc")
-- UNTESTED --
No messing around with globals this way, and it's more extendable. And
'globals()["logger"].getChild("someFunc")' reads like a brick.
-
On 12/12/2011 04:28 PM, Steven D'Aprano wrote:
On Mon, 12 Dec 2011 12:13:33 +0100, Jean-Michel Pichavant wrote:
Using the same name for 2 different objects is a bad idea in general.
We have namespaces precisely so you don't need to care about making names
globally unique.
True, but in this c
On Mon, 12 Dec 2011 12:13:33 +0100, Jean-Michel Pichavant wrote:
> Using the same name for 2 different objects is a bad idea in general.
We have namespaces precisely so you don't need to care about making names
globally unique.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Roy Smith wrote:
MRAB wrote:
or use 'globals':
def function(self):
logger = globals()['logger'].getChild('function')
logger.debug('stuff')
logger.debug('other stuff')
Ah-ha! That's precisely what I was looking for. Much appreciated.
Using the sa
Roy Smith wrote:
> I've got a code pattern I use a lot. In each module, I create a logger
> for the entire module and log to it all over:
>
> logger = logging.getLogger('my.module.name')
>
> class Foo:
>def function(self):
> logger.debug('stuff')
> logger.debug('other stuff')
>
On 12/10/2011 7:14 PM, Terry Reedy wrote:
On 12/10/2011 3:47 PM, Roy Smith wrote:
What I really want to do is:
def function(self):
Add a global statement to rebind a global name:
global logger
But I see that that is not what you want to do, which is to override the
global name just within
On 12/10/2011 3:47 PM, Roy Smith wrote:
What I really want to do is:
def function(self):
Add a global statement to rebind a global name:
global logger
logger = logger.getChild('function')
logger.debug('stuff')
logger.debug('other stuff')
which lets me not ha
MRAB wrote:
> or use 'globals':
>
> def function(self):
> logger = globals()['logger'].getChild('function')
> logger.debug('stuff')
> logger.debug('other stuff')
Ah-ha! That's precisely what I was looking for. Much appreciated.
--
http://mail.python.org/mailma
On 10/12/2011 20:47, Roy Smith wrote:
I've got a code pattern I use a lot. In each module, I create a logger
for the entire module and log to it all over:
logger = logging.getLogger('my.module.name')
class Foo:
def function(self):
logger.debug('stuff')
logger.debug('other stu
I've got a code pattern I use a lot. In each module, I create a logger
for the entire module and log to it all over:
logger = logging.getLogger('my.module.name')
class Foo:
def function(self):
logger.debug('stuff')
logger.debug('other stuff')
and so on. This works, but every on
34 matches
Mail list logo
