<div dir="ltr"><div>I know there was a big follow-up already, but I'd like to point out that (while clearly not everyone feels the same) I am personally inclined to set the bar pretty high for refactoring that don't add functionality. It makes crawling through history using e.g. git blame harder, since the person who last refactored the code ends up owning it even though they weren't responsible for all its intricacies (which might separately be blame-able on many different commits).</div><div><br></div><div>And TBH a desire to refactor a lot of code is often a sign of a relatively new contributor who hasn't learned their way around the code yet, so they tend to want to make the code follow their understanding rather than letting their understanding follow the code.</div><div><br></div><div>Also see <a href="https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence">https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence</a><br></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 26, 2018 at 2:03 AM Jeroen Demeyer <<a href="mailto:J.Demeyer@ugent.be" target="_blank">J.Demeyer@ugent.be</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
On <a href="https://github.com/python/cpython/pull/7909" rel="noreferrer" target="_blank">https://github.com/python/cpython/pull/7909</a> I encountered friction <br>
for a PR which I expected to be uncontroversial: it just moves some code <br>
without changing any functionality.<br>
<br>
So basically my question is: is there some CPython policy *against* <br>
refactoring code to make it easier to read and write? (Note that I'm not <br>
talking about pure style issues here)<br>
<br>
Background: cpython has a source file "call.c" (introduced in <br>
<a href="https://github.com/python/cpython/pull/12" rel="noreferrer" target="_blank">https://github.com/python/cpython/pull/12</a>) but the corresponding <br>
declarations are split over several .h files. While working on PEP 580, <br>
I found this slightly confusing. I decided that it would make more sense <br>
to group all these declarations in a new file "call.h". That's what PR <br>
7909 does. In my opinion, the resulting code is easier to read. It also <br>
defines a clear place for declarations of future functionality added to <br>
"call.c" (for example, if we add a public API for FASTCALL). Finally, I <br>
added/clarified a few comments.<br>
<br>
I expected the PR to be either ignored or accepted. However, I received <br>
a negative reaction from Inada Naoki on it.<br>
<br>
I don't mind closing the PR and keeping the status quo if there is a <br>
general agreement. However, I'm afraid that a future reviewer of PEP 580 <br>
might say "your includes are a mess" and he will be right.<br>
<br>
<br>
Jeroen.<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_-3318343626147639305gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>