Agustin Villena a écrit :
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.
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.
--
http://mail.python.org/mailman/listinfo/python-list
