This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients daniel.urban, eric.snow
Date 2011-09-14.05:03:18
SpamBayes Score 3.65462e-09
Marked as misclassified No
Message-id <1315976601.96.0.245968509576.issue12857@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2011-09-14 05:03:22eric.snowsetrecipients: + eric.snow, daniel.urban
2011-09-14 05:03:21eric.snowsetmessageid: <1315976601.96.0.245968509576.issue12857@psf.upfronthosting.co.za>
2011-09-14 05:03:21eric.snowlinkissue12857 messages
2011-09-14 05:03:20eric.snowcreate