Message263892
Serhiy: "Ah, yes, 5dbf3d932a59 partially fixed this optimization."
Since we already talking about hacks, another hack is to hide this private tuple from the GC using _PyObject_GC_UNTRACK(): see attached property_descr_get_gc_untrack.patch.
Note: I dislike my own patch :-D
Serhiy: "661cdbd617b8 can cause problems with recursion and with cached getters. I suggest to revert it."
Even if I don't understand the issue, I concur that the micro-optimization must be reverted. A micro-optimization must not introduce any behaviour change nor segfault :-)
Raymond Hettinger: "Serhiy, I'll thinking the whole optimization ought to be reverted as being too tricky and error-prone for the small benefit. A less aggressive approach would be to have the tuple save a valid object (such as None) instead of NULL. What do you think?"
PyEval_EvalCodeEx() accepts a C array of PyObject* for function arguments, it's used by fast_function() in Pythn/ceval.c. Maybe a new C function can be designed to call a function: it would uses PyEval_EvalCodeEx() to call functions implemented in Python, or create the tuple for functions implemented in C.
It looks like the issue #23910 which introduced the optimization was created for functions implemented in C. So I don't know it's acceptable. But it would be safer and more generic, no? |
|
Date |
User |
Action |
Args |
2016-04-21 07:51:36 | vstinner | set | recipients:
+ vstinner, brett.cannon, rhettinger, ncoghlan, eric.snow, serhiy.storchaka, random832, xiang.zhang |
2016-04-21 07:51:36 | vstinner | set | messageid: <1461225096.88.0.6388438598.issue26811@psf.upfronthosting.co.za> |
2016-04-21 07:51:36 | vstinner | link | issue26811 messages |
2016-04-21 07:51:36 | vstinner | create | |
|