[C++-sig] [docs][pyste] wrapper class

[David Abrahams]

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> And this is the fundamental problem with the BPL docs - it's good at
> the very high level (the tutorial) and it's good at the very low
> level (the reference manual), but there's a huge chasm in between
> filled only by the testsuite. And unfortunately, that's where a lot
> of people want to be.  But well, you've heard me on this ad nauseum
> and I'm not prepared to write extensive amounts of additional docs
> for you, so I'll just shut up.

Oh, I'd love to fill the gap, but I don't know what, specifically, to
do about it.

>> > I did however find this message:
>> >
>> > http://mail.python.org/pipermail/c++-sig/2004-July/007826.html
>> >
>> > Now plus or minus a few items, this is what I was looking for. It's
>> > rather a shame this isn't in the docs
>> 
>> Well, I just went through the docs looking for a good place to put the
>> information about the differences between the old way and the new way,
>> but couldn't find one.  Any suggestions?  Can you suggest a place
>> where you would have actually looked for it?
>
> I'd have stuck it in the tutorial where the Class Virtual Functions 
> is. I would have said something like:
>
> "There are two ways of wrapping polymorphic functions: (i) the new 
> way and (ii) the old way. The pros & cons of each are <table of 
> both>".

There are no pros to the old way; that's why I don't want it in the
tutorial: it's a poor investment in the future (assuming there will be
more Boost.Python users than there have been some day).  Also, it
seems to me that the only people that's going to help are those who
aren't reading the tutorial.  If you had been reading the tutorial, I
presume you would have noticed that something was different.

I could put this in the FAQ, but then it's not exactly "frequently
asked."  Maybe in the question on dangling references, although it
might be a little out of place there.

> If you don't want to confuse people, you could simply mention that 
> there was an old way based on call_method and the interested reader 
> should go search old Boost docs or c++-sig. You should still mention 
> why the new way is better. BTW, I agree wholeheartedly that the new 
> way is better in every way I can see.
>
> BTW, in this new way, if I still want the PyObject *self do I 
> extract<> it in the constructor because I can't see where wrapper<> 
> lets you have access to it? 

I wouldn't do it in the constructor unless you really want to store
another copy of it, but yeah, extract<> seems like a possibility.

> I ask only because my base object class has two special virtual
> functions just for python which allow internal code to distinguish
> between C++ and python wrapped object instances - most importantly,
> to gain its python side representation which isn't as easy with the
> new polymorphism support.

If that functionality is important, maybe we need to expose the
get_owner function to users.

> Another question: Does get_override() enter the python library at any 
> stage? 

Sure.

> Would it be safe to call with the python GIL unlocked?

I don't think so.

>> > I'd imagine pyste could be patched easily enough. I've added it to
>> > my todo list for the v0.86 release of TnFOX. As before, I'll submit
>> > the new version here.
>> 
>> That'd be great, thanks.
>
> It's no problem, though pyste's design makes extending it in more 
> useful ways tricky. There are too many hidden dependencies and the 
> IDLE debugger has an annoying knack of not seeing any changes you 
> make after the first test run :(

Yeah, you have to restart it.  I think there are better tools out
there that will start a fresh Python for each testing run, but not
sure.

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