Showing the method's class in expection's traceback

[Agustin Villena]

To this therad, I received 2 kinds of anwsers:
- some that help me in
- and other where some guy thinks that has the right to rule if my
need has some value

Thanksfully, Python is an open platform, and with the help obtained
here, now I can fullfill my needs.
Who is the arrogant?

On 22 mayo, 11:59, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> 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 tracebackshowonly 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.