On May 22, 5:19 am, Bruno Desthuilliers <bruno. [EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
