[C++-sig] Re: Tutorial - Techniques

[Nicodemus]

David Abrahams wrote:

>Dirk Gerrits <dirk at gerrits.homeip.net> writes:
>
>  
>
>>Nicodemus wrote:
>>    
>>
>>>I created three sections, "Creating Packages", "Extending Wrapped
>>>Objects in Python" and "Reducing Compiling Time". Any comments are
>>>welcome!
>>>      
>>>
>>Just two minor nits about "Extending Wrapped Objects in Python":
>>
>>* advantages is misspelled 'advantagens'
>>* the term 'syntax sugar' is used, I thought it was 'syntactic sugar'?
>>    
>>
>
>I agree with Dirk; you did a wonderful job and I'm eager to get this
>into CVS!
>

Thanks!

>---
>A few more nits:
>
>the comment in the 2nd code box makes it too wide
>
>"Compiling this files will generate the following Python extensions"
>           ^^^^
>          "these"
>  
>

Fixed.

>That module renaming/packagizing thing is only one way to add Pure
>Python methods.  You might discuss other ways.  For example,
>sounds/__init__.py can add them directly (though that causes
>submodules to load early), or you can use the ihooks module to install
>an import hook from sounds/__init__.py, which, when you load
>sounds/foo.pyd, also loads sounds/_foo.py (or even foo.py!) and merges
>definitions, even merging functions from same-named classes.  Why
>ihooks isn't documented in the standard module docs, I'll never know
>;-).  It's only mentioned here
>http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-64, but
>you can always:
>
>    >>> import ihooks
>    >>> help(ihooks)
>
>This solution might not be as simple to get started, but a single
>prepackaged __init__ could handle this for people so that they only
>need to write the pure python file.  OTOH, maybe that's more than you
>want to get into.  If Ralf is doing this sort of thing a lot, perhaps
>he'll want to implement that.
>  
>

Hmm... I didn't know about ihooks. I will take a look, thanks Dave.
If Ralf wants to contribute with something, I will gladly put it into 
the text.

>"But if we let it like this" should be "But if we leave it that way".
>  
>

Fixed.

>Did you actually test your MetaInjector thing?  I'm pretty sure you
>need to derive the metaclass from the metaclass used for Boost.Python
>objects, or you'll get a metaclass conflict.
>

Silly me! I did test, but with a pure Python class! 8P

Indeed, trying to inject methods in a Boost.Python class gives an error: 
"TypeError: metatype conflict among bases". So I tried to use your 
MetaInjector, but it gives the same error. Any idea?

>About reducing compilation time: this section is very closely related
>to http://www.boost.org/libs/python/doc/v2/faq.html#c1204.  Should we
>cross-link them somehow?
>

I added a blurb to the end of that section pointing to the FAQ.