[Python-Dev] Policy on refactoring/clean up

Jeroen Demeyer J.Demeyer at UGent.be
Tue Jun 26 05:00:48 EDT 2018


On https://github.com/python/cpython/pull/7909 I encountered friction 
for a PR which I expected to be uncontroversial: it just moves some code 
without changing any functionality.

So basically my question is: is there some CPython policy *against* 
refactoring code to make it easier to read and write? (Note that I'm not 
talking about pure style issues here)

Background: cpython has a source file "call.c" (introduced in 
https://github.com/python/cpython/pull/12) but the corresponding 
declarations are split over several .h files. While working on PEP 580, 
I found this slightly confusing. I decided that it would make more sense 
to group all these declarations in a new file "call.h". That's what PR 
7909 does. In my opinion, the resulting code is easier to read. It also 
defines a clear place for declarations of future functionality added to 
"call.c" (for example, if we add a public API for FASTCALL). Finally, I 
added/clarified a few comments.

I expected the PR to be either ignored or accepted. However, I received 
a negative reaction from Inada Naoki on it.

I don't mind closing the PR and keeping the status quo if there is a 
general agreement. However, I'm afraid that a future reviewer of PEP 580 
might say "your includes are a mess" and he will be right.


More information about the Python-Dev mailing list