Eric Snow <ericsnowcurren...@gmail.com> added the comment:
Finally had a chance to get back to this. Here's a new patch in response to
Nick's review.
My only concern is the new _PyEval_EvalFunctionCode function. It is basically
the existing PyEval_EvalCodeEx function with an extra parameter. I've turned
PyEval_EvalCodeEx() into a very light wrapper around
_PyEval_EvalFunctionCode(). This is how I tackled the backwards
incompatibility of my previous patch. However, I am nervous about messing
around with something like PyEval_EvalCodeEx().
I was toying with the idea of doing a more comprehensive refactor involving
call_function, fast_function, and do_call, which seems like it would be a
better fix. However, I'm even more reticent to make that scale of changes,
especially on something so critical, even if it seems right to me currently.
I figured the safe thing for now would be to name the new function with a
leading underscore to mark it as private.
Here are the results from my cursory check before and after my latest patch:
BEFORE
3 tests failed:
test_distutils test_packaging test_socket
[293234 refs]
real 14m40.578s
user 11m43.547s
sys 0m52.096s
AFTER
3 tests failed:
test_distutils test_packaging test_socket
[293171 refs]
real 14m33.785s
user 11m55.437s
sys 0m53.850s
----------
Added file: http://bugs.python.org/file23149/called_function_2.diff
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12857>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
