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

[David Abrahams]

martin@v.loewis.de (Martin v. L=F6wis) writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> Anyway, the point is that I'd like to have the rule changed to "You
>> have to include Python.h or xxxx.h before any system header" where
>> xxxx.h is one of the other existing headers #included in Python.h that
>> is responsible for setting up whatever macros cause this
>> inclusion-order requirement in the first place (preferably not
>> LongObject.h!)
>
> If I understand correctly, you want to follow the rule "I want to
> change things as long it continues to work for me".=20

Then you don't understand correctly.

> For that, you don't need any permission. If it works for you, you
> can ignore any rules you feel uncomfortable with.
>
> The rule is there for people who don't want to understand the
> specific details of system configuration. If you manage to get a
> consistent configuration in a different way, just go for it. You
> should make sure then that your users can't run into problems,
> though.

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.

The current rule doesn't work for me, 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?

--=20
Dave Abrahams
Boost Consulting
www.boost-consulting.com