[Python-Dev] more-precise instructions for "Python.h first"?

[Tim Peters]

[David Abrahams]
> ...
> I can't make sure that my users can't run into problems without
> understanding everything about Python and Posix which causes the rule
> to exist in the first place (and I don't), and continuously monitoring
> Python into the future to make sure that the distribution of Posix
> configuration information across its headers doesn't change in a way
> that invalidates previous assumptions.

Well, we're in the same boat:  we can't ensure that Python users can't run
into problems without knowing everything about how the union of all flaky
platform headers (not just POSIX) will work for all time either.  We do know
that, historically, we've been able to hack around all problems that have
arisen by sticking Python.h first.  There's no guarantee that will always
work, though.

> The current rule doesn't work for me,

It doesn't work for us either, at least not on principle.  It just happens
to have "been enough" in practice so far.

> but I'd like to be following _some_ sanctioned rule to reduce the
> chance of problems today and in the future. I'm making an educated
> guess that the rule is much more-sweeping than Python development
> needs it to be.  Isn't there some Python internal configuration header
> which can be #included first and which will accomplish all the same
> things as far as system-header inclusion order is concerned?

Sorry, I don't know.  I do know that changes to the headers are usually
followed by problems on some handful of systems that can't be predicted in
advance.  I'll note that life is much easier if you drop support for all
systems other than Win32 <wink>.