On Mon, 24 Mar 2008 06:48:10 -0700, Arnaud Delobelle wrote: > On Mar 24, 1:26 pm, Steven D'Aprano <[EMAIL PROTECTED] > cybersource.com.au> wrote: >> On Mon, 24 Mar 2008 04:33:53 -0400, Terry Reedy wrote: >> > The fact that .func_name (which is writeable) is not used at first >> > surprised me until I remembered that code objects can potentially be >> > used by multiple function objects and hence are not connected to any >> > one in particular. >> >> How does that happen? > > Like this: > >>>> def foomaker(x): > ... def foo(y): return x+y > ... return foo > ... >>>> foo1 = foomaker(1) >>>> foo2 = foomaker(2) >>>> foo1.func_code > <code object foo at 0x73530, file "<stdin>", line 2> >>>> foo2.func_code > <code object foo at 0x73530, file "<stdin>", line 2>
Ah, that makes sense. And obvious in hindsight. > Of course foo1 and foo2 are not the same thing: Naturally not. They are different functions. The fact that they share a small part (func_code) is irrelevant. There's more to a function than the code object. >> And if it is the case, what's the justification for giving them a >> co_name attribute? Surely the name of the function should be that of >> the function object, not of one of the shared parts? > >>>> foo1.__name__ > 'foo' >>>> foo1.func_code.co_name > 'foo' > > As seen above, func.__name__ and func.func_code.co_name are the same > thing (until tampered with). Yes, but what I'm asking is why the code objects have a co_name attribute. And even if there's a good reason for code objects to have a name, why do tracebacks use func.func_code.co_name instead of func.__name__? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
