Boost.Python is now trying hard to accomodate the "Python.h before
system headers rule". Unfortunately, we still need a wrapper around
Python.h, at least for some versions of Python, so that we can
work around some issues like:
// Python's LongObject.h helpfully #defines ULONGLONG_MAX for us
// even when it's not defined by the system which confuses Boost's
To cope with that correctly, we need to see <limits.h> (a system
header) before longobject.h. Currently, we're including <limits.h>,
then <patchlevel.h>, well, and then the wrapper gets a little
complicated adjusting for various compilers.
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!) That way I might be able to get those configuration
issues sorted out without violating the #inclusion order rule. What
I have now seems to work, but I'd rather do the right thing (TM).
Thanks for the first round of comments.
Here is a second draft:
* various grammatical, punctuation, etc
* changed variable names between examples
* discuss data and non-data descriptors
* show the precedence of the data vs non-data descriptors
* moved the C code references inside the Python code
* eliminated the python code for obj.__getattribute__
because code was complex enough to hide the discussion points
When this one is done, will use it as a basis for
updating the official docs.
The final version of this will be done through
docutils with reStructured text. That ought to
take care of the vagaries of converting a Word
document to html.
At 08:57 AM 6/1/03 -0400, Guido van Rossum wrote:
>(I'd like to review this more carefully when I have more time, but one
>thing jumped out at me:)
> > It would be a good idea to add some information about "data" and
> > "non-data" descriptors, and the differences of how their attribute
> > lookup is processed. I recently posted here about the "attribute
> > lookup process" or something to that effect, which covered this.
> > Understanding data vs. non-data descriptors is important if you want
> > to do pretty much anything with descriptors beyond what property()
> > does.
>Note that I recently changed the treatment of data descriptors by
>super() in 2.3. typeobject.c rev 2.227/2.228:
And an important change it is. If you define methods on metaclasses that
might also be defined by their instances (i.e. the classes) on behalf of
*their* instances, the only way to get this to work right is to use data
descriptors for the metaclass level methods. Which then means super()
breaks, so for 2.2 I have a custom 'super()' to work with data
descriptors. I rather wish you'd considered it a bugfix rather than a new
In the spirit of Michele Simionato's write-up on method resolution order, I've written up almost everything I know about
* Defines a descriptor
* Shows the protocol and how it is called
* Shows a handmade descriptor
* Then covers functions, properties, static and class methods
* Gives examples of each
* Suggests when each would be useful
* Gives a pure python definition of each
* Provides exact references into C source to save efforts in hunting down details
I would like to hammer this into something really useful. So, any and all suggestions are welcome.
P.S. I've borrowed Alex Martelli's style of making precise descriptions of how the CPython works by showing pure Python