Showing the method's class in expection's traceback

[Agustin Villena]

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.

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 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