Message187003
Here's another new version of the patch, addressing Ezio's review comments and a few things I found after giving operator.py a closer look myself.
Things changed in operator.py in this version:
- all ``__func__ = func`` assignments are moved to the end, after importing * from _operator. With the assignments after each func, __func__ was still the Python version after importing from _operator. I suspect this means that _operator.c could be changed to not mess with creating each __func__ and just let operator.py do it, but not being a native C speaker, I don't know how to do it. Also, there is an added test case to test whether __func__ is func. It passes with the rest of the patch, but would fail on current operator.c; it seems that operator.c actually creates separate __func__ and func functions (that do the same thing).
- If importing from _operator succeeds, import __doc__ from _operator as well. The Python implementation has an extra note at the end of __doc__ advertising that it is a Python implementation.
Also, after submitting this patch, I'm going to try to clean up the files list on this issue a bit. I'll clear the nosy list while I do so to avoid spamming everybody with messages about it. (At least, I assume I can do so, I haven't tried this before :). If I can't clear the nosy list, I won't bother with cleaning up the files, again to avoid spamming) |
|
Date |
User |
Action |
Args |
2013-04-15 16:01:06 | zach.ware | set | recipients:
+ zach.ware, brett.cannon, jcea, pitrou, ezio.melotti, eric.araujo, Arfrever, meador.inge, serhiy.storchaka |
2013-04-15 16:01:06 | zach.ware | set | messageid: <1366041666.08.0.389959097358.issue16694@psf.upfronthosting.co.za> |
2013-04-15 16:01:06 | zach.ware | link | issue16694 messages |
2013-04-15 16:01:05 | zach.ware | create | |
|