[Python-Dev] Policy on refactoring/clean up (original) (raw)

Victor Stinner vstinner at redhat.com
Tue Jun 26 07:31:32 EDT 2018

Hi,

I created call.c when I worked on optimizations. I saw that performances depend on the code locality and that compilers are more eager to inline code when it's in the same file. Moreover, call.c now contains some private functions like function_code_fastcall() or _PyObject_CallFunctionVa() which are called from other public functions. Without call.c, some of these functions should be make "public" (exposed) which has also an impact on performance. Putting all these functions in the same file helps the compiler to produce more efficient code, but should also prevent inconsistencies when we modify a calling convention.

I'm not sure of the rationale behind the proposed call.h header. Is it difficult to maintain actual definitions in multiple header files? I'm used to them, it's easy to discover them, so I am not really convinced that call.h adds any value. I also expect fewer changes in header changes than in the implementation (call.c).

Victor

2018-06-26 11:11 GMT+02:00 INADA Naoki <songofacandy at gmail.com>:

FYI, I don't against general refactoring, when I agree it's really make code cleaner, readable.

I against your PR because I didn't feel it really make code cleaner, readable. I already commented about it on the PR. https://github.com/python/cpython/pull/7909#issuecomment-400219905 So it's not problem about general policy about refactoring / clean up. It's just my preference. If Victor and Serhiy prefer the PR, I'm OK to merge it. Regards, -- INADA Naoki <songofacandy at gmail.com>

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com

More information about the Python-Dev mailing list