Author vstinner
Recipients methane, python-dev, rhettinger, serhiy.storchaka, vstinner, yselivanov
Date 2017-02-09.22:22:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1486678940.9.0.937384597814.issue29507@psf.upfronthosting.co.za>
In-reply-to
Content
Naoki: "method_fastcall4.patch looks clean enough, and performance benefit seems nice."

Ok, I pushed the patch with minor changes:

* replace "variants:" with "Variants:"
* rename lookup_maybe_unbound() to lookup_maybe_method()
* rename lookup_method_unbound() to lookup_method()


"I don't know current test suite covers unusual special methods."

What do you mean by "unusual special methods"?


"Maybe, we can extend test_class to cover !unbound (e.g. @classmethod) case."

It's hard to test all cases, since they are a lot of function types in Python, and each slot (wrapper in typeobject.c) has its own C implementation.

But yeah, in general more tests don't harm :-)

Since the patch here optimizes the most common case, a regular method implemented in Python, I didn't add a specific test with the change. This case is already very well tested, like everything in the stdlib, no?

--

I tried to imagine how we could avoid temporary method objects in more cases like Python class methods (using @classmethod), but I don't think that it's worth it.

It would require more complex code for a less common case. Or do someone see other common cases which would benefit of a similar optimization?
History
Date User Action Args
2017-02-09 22:22:20vstinnersetrecipients: + vstinner, rhettinger, methane, python-dev, serhiy.storchaka, yselivanov
2017-02-09 22:22:20vstinnersetmessageid: <1486678940.9.0.937384597814.issue29507@psf.upfronthosting.co.za>
2017-02-09 22:22:20vstinnerlinkissue29507 messages
2017-02-09 22:22:20vstinnercreate