Showing the method's class in expection's traceback

[Bruno Desthuilliers]

Agustin Villena a écrit :
> On May 22, 5:19 am, Bruno Desthuilliers <bruno.
> 42.desthuilli... at websiteburo.invalid> wrote:
>> Agustin Villena a écrit :
>>
>>>> And not that useful - why would one care about the function being
>>>> defined in class X or Y when one have the exact file and line ?
>>> I have 3 reasons:
>>> 1) My developing time is expended running unit tests and browsing
>>> tracebacks to find which is the real problem. Knowing the offender
>>> class (instead of the method alone) makes me understand more quickly
>>> which component of my software is failing.
>> This is only true when there is an obvious, one-to-one, unambiguous
>> relationship between the physical location of the error (file, line) and
>> the class of the object the method has been called on. Which is not
>> necessarily the case (inheritance, method decoration and monkeypatching
>> comes to mind here...).
>>
>> Also, your above statement seems to imply that component==class, which
>> is not the case in Python.
>>
>>> 2) There are some ocassions where I only have the traceback (e.g. when
>>> analyzing an app's log) and no inmediate access to teh source code
>> Ok. But the above still apply...
>>
>>> 3) And finally, for completeness: If a function is really a method, if
>>> the traceback show only its name and not the class that defines it,
>>> for me its a bug, because the method name has no sense out of its
>>> class.
>> I'm not sure you really grasp what "methods" are in Python. What you
>> define (using the def statement) within a class is function, not a
>> method. It only becomes a method when it's looked up on an instance or
>> class object, and this 'method' is only a thin wrapper around the
>> instance, class and function objects. And FWIW, you don't need to define
>> the function within the class to make it a method:
>>
>> # bar.py
>> def bar(obj):
>>    print "function bar.bar called on obj %s" % obj
>>
>> # foo.py
>>
>> class Foo(object): pass
>>
>> # baaz.py
>> from foo import Foo
>> import bar
>>
>> Foo.baaz = bar.bar
>>
>> def guux(obj):
>>    print "function baaz.guux called on obj %s" % obj
>>
>> # main.py
>> from baaz import Foo
>> f = Foo()
>> f.bar()
>>
>> f.gnix = baae.guux.__get__(f, type(f))
>> f.gnix()
>>
>> Not to say that your concerns are pointless, and that things cannot be
>> improved somehow, but this is not that trivial, and there may be
>> ambuiguities in some not so rare cases.
> 
> Well, the solution given in an early response is good enough for me.

Not for me.

> I don't see things like you, because I'm accustomed to design my
> software
> though classes and see the code in an "object = software's functional
> atom/component" way

I guess you mean 'class = software's functional atom/component' - 
because it's perfectly legal, in Python, to have per-instance methods...

Now the fact that *you* see it that way doesn't mean Python (and most 
Python users) have to share your views, so labelling the way it works as 
"a bug" sounds a bit arrogant to me.

> I agree that python's dynamic nature make things complicated here, but
> for me it its just
> an implementation problem derived of the recent OOP support of python

I beg your pardon ? "recent OOP support in Python" ? Python had classes 
and objects years before Oak was renamed as Java and made public, you know.