Re: [Python-Dev] Policy on refactoring/clean up

[Kyle]

In itself, the code clean up you have done is a good thing in the sense
that you re-organized things and in my understanding, they look good now.
In some of the teams I've been granted to work, there was a rule stating
that whenever a dev would work on an enhancement/bugfix, he would create a
separate ticket that would track all code refactoring related to his work.
The strategy is quite different here and the suggestion was to have your
refactoring be part of an enhancement/bugfix. The most valuable argument in
favor of all the current reviewers is Guido van Rossum's comment on the
effect of having git blame made harder.
For some of the projects I'm currently working on, we have code cleanup
teams where members are affected expressly to refactoring code. We might
end up needing such things in the future but for now, it is wiser to leave
the code as is and focus on fixing actual problems.

-- 
*Q::Drone's Co-Founder and Co-CEO*
 *Hervé "Kyle" MUTOMBO*

*Envoyé depuis le web.*
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[INADA Naoki]

On Wed, Jun 27, 2018 at 2:27 PM Jeroen Demeyer  wrote:

> On 2018-06-27 00:02, Guido van Rossum wrote:
> > 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.
>
> ...or it could be that the code is written the way it is only for
> historical reasons, instead of bei
> ​​
> ng purposely written that way.
>

In
​​
this
​time, I suppose you thought .c <=> .h filename should be matched.
And we don't think so.

Header files are organized for exposing APIs,
and source files are
organized for implementing
​the ​
APIs.
​Since goal is different,
they
​aren't​
match
​ed​
always.​
​​

​Regards,​
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Jeroen Demeyer]

On 2018-06-27 00:02, Guido van Rossum wrote:

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.


...or it could be that the code is written the way it is only for 
historical reasons, instead of being purposely written that way.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Guido van Rossum]

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).

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.

Also see https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence


On Tue, Jun 26, 2018 at 2:03 AM Jeroen Demeyer  wrote:

> Hello,
>
> 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.
>
>
> Jeroen.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Ivan Pozdeev via Python-Dev]

On 26.06.2018 14:54, Ivan Pozdeev via Python-Dev wrote:

On 26.06.2018 14:43, Jeroen Demeyer wrote:

On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote:

AFAICS, your PR is not a strict improvement


What does "strict improvement" even mean? Many changes are not strict 
improvements, but still useful to have.


Inada pointed me to YAGNI 
(https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) but I 
disagree with that premise: there is a large gray zone between 
"completely useless" and "really needed". My PR falls in that gap of 
"nice to have but we can do without it".



You may suggest it as a supplemental PR to PEP 580. Or even a part of
it, but since the changes are controversial, better make the
refactorings into separate commits so they can be rolled back 
separately

if needed.


If those refactorings are rejected now, won't they be rejected as 
part of PEP 580 also?


This is exactly what that the YAGNI principle is about, and Inada was 
right to point to it.


Strike this part out since he didn't actually say that as it turned out.

Until you have an immediate practical need for something, you don't 
really know the shape and form for it that you will be the most 
comfortable with. Thus any "would be nice to have" tinkerings are 
essentially a waste of time and possibly a degradation, too: you'll 
very likely have to change them again when the real need arises -- 
while having to live with any drawbacks in the meantime.


So, if you suggest those changes together with the PEP 580 PR, they 
will be reviewed through the prism of the new codebase and its needs, 
which are different from the current codebase and its needs.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru




--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Petr Viktorin]

On 06/26/18 14:13, Jeroen Demeyer wrote:

On 2018-06-26 13:54, Ivan Pozdeev via Python-Dev wrote:

This is exactly what that the YAGNI principle is about, and Inada was
right to point to it. Until you have an immediate practical need for
something, you don't really know the shape and form for it that you will
be the most comfortable with. Thus any "would be nice to have"
tinkerings are essentially a waste of time and possibly a degradation,
too: you'll very likely have to change them again when the real need
arises -- while having to live with any drawbacks in the meantime.


It is important to clarify that this is exactly what I did. I *have* an 
implementation of PEP 580 and it's based on that PR 7909.


I just think that this PR makes sense independently of whether PEP 580 
will be accepted.



So, if you suggest those changes together with the PEP 580 PR


That sounds like a bad idea because that would be mixing two issues in 
one PR. If I want to increase my chances of getting PEP 580 and its 
implementation accepted, I shouldn't bring in unrelated changes.


To put it in a different perspective: if somebody else would make a PR 
to one of my projects doing a refactoring and adding new features, I 
would ask them to split it up.


Actually, that's exactly what we *did* ask Jeroen with his earlier 
proposal for PEP 575, where the implementation ended up being quite big. 
Split the changes to make it more manageable.


Unfortunately I haven't had time to study this PR yet (work is taking 
all my time lately), but I trust that Jeroen will propose actual 
improvements on top of the clean-up.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Jeroen Demeyer]

On 2018-06-26 13:54, INADA Naoki wrote:

Real need is important than my preference.  If it is needed PEP 580, I'm OK.


Of course it's not needed. I never claimed that it was.

I think it's *nice to have* right now and slightly more *nice to have* 
when changes/additions are made to call.c in the future.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Jeroen Demeyer]

On 2018-06-26 13:54, Ivan Pozdeev via Python-Dev wrote:

This is exactly what that the YAGNI principle is about, and Inada was
right to point to it. Until you have an immediate practical need for
something, you don't really know the shape and form for it that you will
be the most comfortable with. Thus any "would be nice to have"
tinkerings are essentially a waste of time and possibly a degradation,
too: you'll very likely have to change them again when the real need
arises -- while having to live with any drawbacks in the meantime.


It is important to clarify that this is exactly what I did. I *have* an 
implementation of PEP 580 and it's based on that PR 7909.


I just think that this PR makes sense independently of whether PEP 580 
will be accepted.



So, if you suggest those changes together with the PEP 580 PR


That sounds like a bad idea because that would be mixing two issues in 
one PR. If I want to increase my chances of getting PEP 580 and its 
implementation accepted, I shouldn't bring in unrelated changes.


To put it in a different perspective: if somebody else would make a PR 
to one of my projects doing a refactoring and adding new features, I 
would ask them to split it up.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Antoine Pitrou]

On Tue, 26 Jun 2018 11:00:48 +0200
Jeroen Demeyer  wrote:
> Hello,
> 
> 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)

I think refactorings are generally ok, assuming they bring a
substantial maintainability or readability benefit.  I haven't studied
your PR enough to decide whether that's the case for the changes you
are proposing, though.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Ivan Pozdeev via Python-Dev]

On 26.06.2018 14:54, INADA Naoki wrote:


On Tue, Jun 26, 2018 at 8:46 PM Jeroen Demeyer > wrote:


On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote:
> AFAICS, your PR is not a strict improvement

What does "strict improvement" even mean? Many changes are not strict
improvements, but still useful to have.

Inada pointed me to YAGNI


​No, YAGNI is posted by someone and they removed their comment.


Yes, that was me instead.
I posted it and then changed my mind. Apparently, notifications were 
sent nonetheless.

I didn't watch the thread and kinda assumed that you pointed that out, too.
(Just to put everything straight and not make anyone suspect I'm trying 
to pull the wool over anyone's eyes here.)




My point was:

Moving code around makes:

  * hard to track history.

  * hard to backport patches to old branches.

https://github.com/python/cpython/pull/7909#issuecomment-400219905

And I prefer keeping definitions relating to​ methods in methodobject.h to
move them to call.h only because they're used/implemented in call.c

(https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) but I
disagree with that premise: there is a large gray zone between
"completely useless" and "really needed". My PR falls in that gap of
"nice to have but we can do without it".


​So I didn't think even it is "nice to have".​

> You may suggest it as a supplemental PR to PEP 580. Or even a
part of
> it, but since the changes are controversial, better make the
> refactorings into separate commits so they can be rolled back
separately
> if needed.

If those refactorings are rejected now, won't they be rejected as
part
of PEP 580 also?


Real need is important than my preference.  If it is needed PEP 580, 
I'm OK.

But I didn't know which part of the PR is required by PEP 580.

Regards,

--
INADA Naoki  mailto:songofaca...@gmail.com>>


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Jeroen Demeyer]

On 2018-06-26 13:54, INADA Naoki wrote:

​No, YAGNI is posted by someone and they removed their comment.


Sorry for that, I misunderstood the email that GitHub sent me.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[INADA Naoki]

On Tue, Jun 26, 2018 at 8:46 PM Jeroen Demeyer  wrote:

> On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote:
> > AFAICS, your PR is not a strict improvement
>
> What does "strict improvement" even mean? Many changes are not strict
> improvements, but still useful to have.
>
> Inada pointed me to YAGNI
>

​No, YAGNI is posted by someone and they removed their comment.

My point was:

Moving code around makes:
>
>- hard to track history.
>
>
>- hard to backport patches to old branches.
>
>  https://github.com/python/cpython/pull/7909#issuecomment-400219905

And I prefer keeping definitions relating to​ methods in methodobject.h to
move them to call.h only because they're used/implemented in call.c



> (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) but I
> disagree with that premise: there is a large gray zone between
> "completely useless" and "really needed". My PR falls in that gap of
> "nice to have but we can do without it".
>
>
​So I didn't think even it is "nice to have".​



> > You may suggest it as a supplemental PR to PEP 580. Or even a part of
> > it, but since the changes are controversial, better make the
> > refactorings into separate commits so they can be rolled back separately
> > if needed.
>
> If those refactorings are rejected now, won't they be rejected as part
> of PEP 580 also?
>

Real need is important than my preference.  If it is needed PEP 580, I'm OK.
But I didn't know which part of the PR is required by PEP 580.

Regards,

-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Ivan Pozdeev via Python-Dev]

On 26.06.2018 14:43, Jeroen Demeyer wrote:

On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote:

AFAICS, your PR is not a strict improvement


What does "strict improvement" even mean? Many changes are not strict 
improvements, but still useful to have.


Inada pointed me to YAGNI 
(https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) but I 
disagree with that premise: there is a large gray zone between 
"completely useless" and "really needed". My PR falls in that gap of 
"nice to have but we can do without it".



You may suggest it as a supplemental PR to PEP 580. Or even a part of
it, but since the changes are controversial, better make the
refactorings into separate commits so they can be rolled back separately
if needed.


If those refactorings are rejected now, won't they be rejected as part 
of PEP 580 also?


This is exactly what that the YAGNI principle is about, and Inada was 
right to point to it. Until you have an immediate practical need for 
something, you don't really know the shape and form for it that you will 
be the most comfortable with. Thus any "would be nice to have" 
tinkerings are essentially a waste of time and possibly a degradation, 
too: you'll very likely have to change them again when the real need 
arises -- while having to live with any drawbacks in the meantime.


So, if you suggest those changes together with the PEP 580 PR, they will 
be reviewed through the prism of the new codebase and its needs, which 
are different from the current codebase and its needs.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Jeroen Demeyer]

On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote:

AFAICS, your PR is not a strict improvement


What does "strict improvement" even mean? Many changes are not strict 
improvements, but still useful to have.


Inada pointed me to YAGNI 
(https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) but I 
disagree with that premise: there is a large gray zone between 
"completely useless" and "really needed". My PR falls in that gap of 
"nice to have but we can do without it".



You may suggest it as a supplemental PR to PEP 580. Or even a part of
it, but since the changes are controversial, better make the
refactorings into separate commits so they can be rolled back separately
if needed.


If those refactorings are rejected now, won't they be rejected as part 
of PEP 580 also?

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Victor Stinner]

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 :
> 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  
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Ivan Pozdeev via Python-Dev]

On 26.06.2018 12:00, Jeroen Demeyer wrote:

Hello,

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.


AFAICS, your PR is not a strict improvement, that's the reason for the 
"friction".
You may suggest it as a supplemental PR to PEP 580. Or even a part of 
it, but since the changes are controversial, better make the 
refactorings into separate commits so they can be rolled back separately 
if needed.




Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[Serhiy Storchaka]

26.06.18 12:11, INADA Naoki пише:
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.


I'm with Inada.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

[INADA Naoki]

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  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Policy on refactoring/clean up

[Jeroen Demeyer]

Hello,

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.



Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com