Guido van Rossum added the comment: OK. Some code review comments:
- Please clean up the comment in classobject.c starting with "Method objects are used for one purposes:" -- to begin with, "one purposes" is ungrammatical. Best to remove the (a) bullet and rephrase the whole thing more like "Method objects are used for bound instance methods (...)" - The error "unbound methods are not supported" sounds a bit strange; better rephrase more positive as "self must not be None" - There is still a comment left "No, it is an unbound method". Is this code still reachable? I though all ways to set im_self to NULL/None are blocked? - Is bug 1202533 still worth testing for in test_descr.py? I don't know that using a lambda reproduces the error condition that once existed. Functional suggestions: - Do we really need im_class for anything any more? ISTM that the one place where it is still used (in method_repr), we could as well use the class of im_self. (And before you think of super() as a counter-argument: super() passes the object's class in rather than the class where the method is found (though this may be considered a bug). - I think that, like func_code -> __code__, the im_xxx attributes should be renamed __xxx__. The 'new' module claims to exist solely for backwards compatibility. If that's true, why are we adding to it? In any case, the _BoundCFunction() class is redundant -- you can just use the "method" type, which is easily accessed as any bound method's __class__ attribute. And is there a use case for an *unbound* C function? If not, you could replace boundcfunction() with just a call to the method type. __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1497> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com