From stefan at seefeld.name  Wed Aug  5 14:23:11 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Wed, 5 Aug 2015 08:23:11 -0400
Subject: [C++-sig] Boost.Python docs update
Message-ID: <55C2002F.3080603@seefeld.name>

Hi all,

I have updated the Boost.Python documentation.

The new docs are available at http://boostorg.github.io/python.
(For any issues you notice please submit a bug report at
https://github.com/boostorg/python/issues.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From bluescarni at gmail.com  Thu Aug  6 16:00:32 2015
From: bluescarni at gmail.com (Francesco Biscani)
Date: Thu, 6 Aug 2015 16:00:32 +0200
Subject: [C++-sig] Boost.Python docs update
In-Reply-To: <55C2002F.3080603@seefeld.name>
References: <55C2002F.3080603@seefeld.name>
Message-ID: <CAHExjCuvbYpDFt=iGZ++OG_2gzmwx0-N44w9Wv6CU947ph-vvQ@mail.gmail.com>

Kudos and thanks a lot, that looks great! (and it must have taken a lot of
effort...)

Cheers,

  Francesco.

On 5 August 2015 at 14:23, Stefan Seefeld <stefan at seefeld.name> wrote:

> Hi all,
>
> I have updated the Boost.Python documentation.
>
> The new docs are available at http://boostorg.github.io/python.
> (For any issues you notice please submit a bug report at
> https://github.com/boostorg/python/issues.
>
> Thanks,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150806/07fdcf6d/attachment.html>

From trigves at yahoo.com  Thu Aug  6 18:12:08 2015
From: trigves at yahoo.com (Trigve Siver)
Date: Thu, 6 Aug 2015 16:12:08 +0000 (UTC)
Subject: [C++-sig] Boost.Python docs update
In-Reply-To: <CAHExjCuvbYpDFt=iGZ++OG_2gzmwx0-N44w9Wv6CU947ph-vvQ@mail.gmail.com>
References: <CAHExjCuvbYpDFt=iGZ++OG_2gzmwx0-N44w9Wv6CU947ph-vvQ@mail.gmail.com>
Message-ID: <143356085.211046.1438877528064.JavaMail.yahoo@mail.yahoo.com>





>________________________________
> From: Francesco Biscani <bluescarni at gmail.com>
>To: Development of Python/C++ integration <cplusplus-sig at python.org> 
>Sent: Thursday, August 6, 2015 4:00 PM
>Subject: Re: [C++-sig] Boost.Python docs update
> 
>
>
>Kudos and thanks a lot, that looks great! (and it must have taken a lot of effort...)
>
>
>Cheers,
>
>
>  Francesco.
>
>
>
>
>
>On 5 August 2015 at 14:23, Stefan Seefeld <stefan at seefeld.name> wrote:
>
>Hi all,
>>
>>I have updated the Boost.Python documentation.
>>
>>The new docs are available at http://boostorg.github.io/python.
>>(For any issues you notice please submit a bug report at
>>https://github.com/boostorg/python/issues.
>>
>>Thanks,
>>                Stefan
>>


Kudos to you from me, too ;)

From mlang at delysid.org  Mon Aug 10 17:00:37 2015
From: mlang at delysid.org (Mario Lang)
Date: Mon, 10 Aug 2015 17:00:37 +0200
Subject: [C++-sig] [Boost.Python] Treating boost::variant like a reference?
Message-ID: <87mvxzfasq.fsf@fx.delysid.org>

Hi.

I am trying (off and on, because it would be useful, but I am not quite
there yet) to find a way to make Boost.Python cooperate with
Boost.Variant.  I sort of managed to make a variant behave like a
value.  However, things like modification of a variant inside of a
container doesn't work, because the variant is converted from/to python
everytime it is accessed.  Looking at the Boost.Python docs and code, I
think there should be a way to treat a variant like a proxy/reference.
The only problem is, that Boost.Python would *know* the C++ type of the
referenced object only at runtime.  While that shouldn't be a problem
for Python,
It looks like Boost.Python doesn't support this.  But maybe there is
some way to still acomplish that, and I have missed it?

boost.variant is common enough that it would be worthwhile to have
boost.python support it as best as possible.  It took me quite a while
to figure out what I have written below, so, in case there is no better
solution, maybe we want to add something about variants to the
boost.python docs to get people started a little easier?

I've written up what I have found so far here:
http://blind.guru/boost_python-and-boost_variant.html

Any input appreciated.

-- 
CYa,
  ?????

From finjulhich at gmail.com  Thu Aug 13 11:24:42 2015
From: finjulhich at gmail.com (MM)
Date: Thu, 13 Aug 2015 10:24:42 +0100
Subject: [C++-sig] express pointer ownership
Message-ID: <CADsB1iButOX8RPR+tdj4RnFkME2-SN3-nGdciMjRpzLvoNDHYw@mail.gmail.com>

I have the following class:

class T {
};
// T has been exposed to python with class_

and free function:

void add_T( T* );

Ownership of the T* is taken by this C++ function.


If I create an instance of the python version of T, how do I "def" the
add_T function?

def("add_T", add_T)

fails to compile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150813/817f4039/attachment.html>

From finjulhich at gmail.com  Thu Aug 13 12:58:42 2015
From: finjulhich at gmail.com (MM)
Date: Thu, 13 Aug 2015 11:58:42 +0100
Subject: [C++-sig] express pointer ownership
In-Reply-To: <CADsB1iButOX8RPR+tdj4RnFkME2-SN3-nGdciMjRpzLvoNDHYw@mail.gmail.com>
References: <CADsB1iButOX8RPR+tdj4RnFkME2-SN3-nGdciMjRpzLvoNDHYw@mail.gmail.com>
Message-ID: <CADsB1iD4BpfG2d7D2=hftYw5ueMUX6CsXoxB4+znyx54k8Kusg@mail.gmail.com>

On 13 August 2015 at 10:24, MM <finjulhich at gmail.com> wrote:

> I have the following class:
>
> class T {
> };
> // T has been exposed to python with class_
>
> and free function:
>
> void add_T( T* );
>
> Ownership of the T* is taken by this C++ function.
>
>
> If I create an instance of the python version of T, how do I "def" the
> add_T function?
>
> def("add_T", add_T)
>
> fails to compile.
>

Apologies. This compiled correctly.

This function:

const T* get_T( const std::string& name );

failed to compile.

so the T pointer is owner by a container in the c++ world, it gets stored
there by add_T,
then the get_T  returns a raw pointer to it. I want to tell python to let
c++ manage it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150813/b6b31292/attachment.html>

From stefan at seefeld.name  Thu Aug 13 13:01:37 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Thu, 13 Aug 2015 07:01:37 -0400
Subject: [C++-sig] express pointer ownership
In-Reply-To: <CADsB1iD4BpfG2d7D2=hftYw5ueMUX6CsXoxB4+znyx54k8Kusg@mail.gmail.com>
References: <CADsB1iButOX8RPR+tdj4RnFkME2-SN3-nGdciMjRpzLvoNDHYw@mail.gmail.com>
 <CADsB1iD4BpfG2d7D2=hftYw5ueMUX6CsXoxB4+znyx54k8Kusg@mail.gmail.com>
Message-ID: <55CC7911.8010707@seefeld.name>

On 13/08/15 06:58 AM, MM wrote:
> On 13 August 2015 at 10:24, MM <finjulhich at gmail.com
> <mailto:finjulhich at gmail.com>> wrote:
>
>     I have the following class:
>
>     class T {
>     };
>     // T has been exposed to python with class_
>
>     and free function:
>
>     void add_T( T* );
>
>     Ownership of the T* is taken by this C++ function.
>
>
>     If I create an instance of the python version of T, how do I "def"
>     the add_T function?
>
>     def("add_T", add_T)
>
>     fails to compile.
>
>
> Apologies. This compiled correctly.
>
> This function: 
>
> const T* get_T( const std::string& name );
>
> failed to compile.
>
> so the T pointer is owner by a container in the c++ world, it gets
> stored there by add_T,
> then the get_T  returns a raw pointer to it. I want to tell python to
> let c++ manage it.

Sounds like you want to use the "return_internal_reference" call policy
(see
http://boostorg.github.io/python/doc/html/tutorial/tutorial/functions.html#tutorial.functions.call_policies).

        Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From finjulhich at gmail.com  Thu Aug 13 13:26:41 2015
From: finjulhich at gmail.com (MM)
Date: Thu, 13 Aug 2015 12:26:41 +0100
Subject: [C++-sig] express pointer ownership
In-Reply-To: <55CC7911.8010707@seefeld.name>
References: <CADsB1iButOX8RPR+tdj4RnFkME2-SN3-nGdciMjRpzLvoNDHYw@mail.gmail.com>
 <CADsB1iD4BpfG2d7D2=hftYw5ueMUX6CsXoxB4+znyx54k8Kusg@mail.gmail.com>
 <55CC7911.8010707@seefeld.name>
Message-ID: <CADsB1iCNri=8SeBnzXdGjLVDaY8NFU_AvekHonk629hQpsaGig@mail.gmail.com>

On 13 August 2015 at 12:01, Stefan Seefeld <stefan at seefeld.name> wrote:

> On 13/08/15 06:58 AM, MM wrote:
> > On 13 August 2015 at 10:24, MM <finjulhich at gmail.com
> > <mailto:finjulhich at gmail.com>> wrote:
> >
> >     I have the following class:
> >
> >     class T {
> >     };
> >     // T has been exposed to python with class_
> >
> >     and free function:
> >
> >     void add_T( T* );
> >
> >     Ownership of the T* is taken by this C++ function.
> >
> >
> >     If I create an instance of the python version of T, how do I "def"
> >     the add_T function?
> >
> >     def("add_T", add_T)
> >
> >     fails to compile.
> >
> >
> > Apologies. This compiled correctly.
> >
> > This function:
> >
> > const T* get_T( const std::string& name );
> >
> > failed to compile.
> >
> > so the T pointer is owner by a container in the c++ world, it gets
> > stored there by add_T,
> > then the get_T  returns a raw pointer to it. I want to tell python to
> > let c++ manage it.
>
> Sounds like you want to use the "return_internal_reference" call policy
> (see
>
> http://boostorg.github.io/python/doc/html/tutorial/tutorial/functions.html#tutorial.functions.call_policies
> ).
>
>         Stefan
>
>
That policy says:

"Ties lifetime of one argument to that of result"

The argument of my function is just the string.... Really its lifetime
doesn't matter....
In the context of a call from python:

t = get_T( 'name1' )

At some point, a std::string temporary must be constructed, holding
'name1'?  and then get_T uses it for lookup.
Once get_T returns   the const T*, it doesn't care about it anymore.

What I want to express is:

The t returned by the python function should refer to object T held in c++
memory, and for instance

del t

should not delete the actual T object in c++ memory

Should I still use "return_internal_reference"  ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150813/63b033c1/attachment.html>

From amohr at pixar.com  Thu Aug 13 18:09:49 2015
From: amohr at pixar.com (Alex Mohr)
Date: Thu, 13 Aug 2015 09:09:49 -0700
Subject: [C++-sig] express pointer ownership
In-Reply-To: <CADsB1iCNri=8SeBnzXdGjLVDaY8NFU_AvekHonk629hQpsaGig@mail.gmail.com>
References: <CADsB1iButOX8RPR+tdj4RnFkME2-SN3-nGdciMjRpzLvoNDHYw@mail.gmail.com>
 <CADsB1iD4BpfG2d7D2=hftYw5ueMUX6CsXoxB4+znyx54k8Kusg@mail.gmail.com>
 <55CC7911.8010707@seefeld.name>
 <CADsB1iCNri=8SeBnzXdGjLVDaY8NFU_AvekHonk629hQpsaGig@mail.gmail.com>
Message-ID: <55CCC14D.5040207@pixar.com>

On 8/13/2015 4:26 AM, MM wrote:
> What I want to express is:
>
> The t returned by the python function should refer to object T held in
> c++ memory, and for instance
>
> del t
>
> should not delete the actual T object in c++ memory
>
> Should I still use "return_internal_reference"  ?

You can use reference_existing_object 
(http://www.boost.org/doc/libs/1_59_0/libs/python/doc/v2/reference_existing_object.html)

But as the docs say, that can be dangerous since if I do 't = get_T()' 
in python and then sometime later C++ deletes the object that t refers 
to, now I have a dangling pointer.  If I try to use 't' in python now I 
have undefined behavior (and likely crash).

Alex


From eu at doxos.eu  Thu Aug 13 14:01:06 2015
From: eu at doxos.eu (=?UTF-8?B?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Thu, 13 Aug 2015 14:01:06 +0200
Subject: [C++-sig] shared_ptr and GIL crash in boost::python (patch)
In-Reply-To: <CAAxjCEwFFGXLw_6zkkio9JCahKpJZ-i9144zU3iesQy7E4YRow@mail.gmail.com>
References: <5549A625.2020007@doxos.eu>
 <CAAxjCEwFFGXLw_6zkkio9JCahKpJZ-i9144zU3iesQy7E4YRow@mail.gmail.com>
Message-ID: <55CC8702.1070402@doxos.eu>


>> I would like to ask someone to look at the patch if it is safe to be
>> applied, and do so. It's been first identified 2 years ago. If I can do
>> something on my part, or other reporters, I am willing to do whatever is
>> necessary to expedite this.
>>
>> Opinions?
> I guess it would be very prone to deadlocks in existing code. I, for
> one, would not welcome such an unexpected change of behavior in a
> minor version upgrade.
I'd suggest to turn this on via an optional argument to the bp::class_ 
template (or using a "global" variable settable at runtime for 
controlling this), would that be an option? While I see the possibility 
of deadlocks (in code which must be broken anyway), ATM what we get is 
segfaults and workarounds for those.

v.

From stefanrin at gmail.com  Sat Aug 15 14:16:18 2015
From: stefanrin at gmail.com (Stefan Ring)
Date: Sat, 15 Aug 2015 14:16:18 +0200
Subject: [C++-sig] [Boost.Python] Treating boost::variant like a
	reference?
In-Reply-To: <87mvxzfasq.fsf@fx.delysid.org>
References: <87mvxzfasq.fsf@fx.delysid.org>
Message-ID: <CAAxjCEx8J7Xir8OHcdS=D_TzKBWSf-ye9tKL7qWLX_v3M9ZvGA@mail.gmail.com>

On Mon, Aug 10, 2015 at 5:00 PM, Mario Lang <mlang at delysid.org> wrote:
> Hi.
>
> I am trying (off and on, because it would be useful, but I am not quite
> there yet) to find a way to make Boost.Python cooperate with
> Boost.Variant.  I sort of managed to make a variant behave like a
> value.  However, things like modification of a variant inside of a
> container doesn't work, because the variant is converted from/to python
> everytime it is accessed.  Looking at the Boost.Python docs and code, I
> think there should be a way to treat a variant like a proxy/reference.
> The only problem is, that Boost.Python would *know* the C++ type of the
> referenced object only at runtime.  While that shouldn't be a problem
> for Python,
> It looks like Boost.Python doesn't support this.  But maybe there is
> some way to still acomplish that, and I have missed it?
>
> boost.variant is common enough that it would be worthwhile to have
> boost.python support it as best as possible.  It took me quite a while
> to figure out what I have written below, so, in case there is no better
> solution, maybe we want to add something about variants to the
> boost.python docs to get people started a little easier?
>
> I've written up what I have found so far here:
> http://blind.guru/boost_python-and-boost_variant.html
>
> Any input appreciated.

Interesting question and interesting blog post! Unfortunately, I don't
have an answer. I'm not familiar enough with Boost.Variant, and I have
not had to dig through Boost.Python reference documentation for quite
a while. I have no idea what is the intended level of interoperability
with Boost.Variant.

From stefan at seefeld.name  Mon Aug 17 14:03:03 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Mon, 17 Aug 2015 08:03:03 -0400
Subject: [C++-sig] virtual functions with default implementation
Message-ID: <55D1CD77.3040708@seefeld.name>

Hi,

I'm reviewing the Boost.Python tutorial, and I'm stumbling over the
section on "Virtual Functions with Default implementations"
(http://boostorg.github.io/python/doc/html/tutorial/tutorial/exposing.html#tutorial.exposing.virtual_functions_with_default_i).
It mentions the need to provide a separate default implementation
function as third argument to "def()", without explaining why that is
needed.
In fact, I'm trying various alternatives (abstract, non-abstract), and I
can't find a need for it. All my tests work fine without it.

Does anyone know why this is needed, and could perhaps even provide a
little test case ?

Thanks,
        Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From nikolay.mladenov at gmail.com  Mon Aug 17 20:12:24 2015
From: nikolay.mladenov at gmail.com (Nikolay Mladenov)
Date: Mon, 17 Aug 2015 14:12:24 -0400
Subject: [C++-sig] virtual functions with default implementation
In-Reply-To: <55D1CD77.3040708@seefeld.name>
References: <55D1CD77.3040708@seefeld.name>
Message-ID: <CACbdn-+nea_BdVzrbpvR-nQQRPbcBrfNx3Wh7pc_bSeqBvjsHA@mail.gmail.com>

If you export an abstract class, create an object from python and call its
virtual from C++ it should not work without the default implementation.

On Mon, Aug 17, 2015 at 8:03 AM, Stefan Seefeld <stefan at seefeld.name> wrote:

> Hi,
>
> I'm reviewing the Boost.Python tutorial, and I'm stumbling over the
> section on "Virtual Functions with Default implementations"
> (
> http://boostorg.github.io/python/doc/html/tutorial/tutorial/exposing.html#tutorial.exposing.virtual_functions_with_default_i
> ).
> It mentions the need to provide a separate default implementation
> function as third argument to "def()", without explaining why that is
> needed.
> In fact, I'm trying various alternatives (abstract, non-abstract), and I
> can't find a need for it. All my tests work fine without it.
>
> Does anyone know why this is needed, and could perhaps even provide a
> little test case ?
>
> Thanks,
>         Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150817/6876dc86/attachment.html>

From stefan at seefeld.name  Mon Aug 17 20:39:32 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Mon, 17 Aug 2015 14:39:32 -0400
Subject: [C++-sig] virtual functions with default implementation
In-Reply-To: <CACbdn-+nea_BdVzrbpvR-nQQRPbcBrfNx3Wh7pc_bSeqBvjsHA@mail.gmail.com>
References: <55D1CD77.3040708@seefeld.name>
 <CACbdn-+nea_BdVzrbpvR-nQQRPbcBrfNx3Wh7pc_bSeqBvjsHA@mail.gmail.com>
Message-ID: <55D22A64.6040603@seefeld.name>

On 17/08/15 02:12 PM, Nikolay Mladenov wrote:
> If you export an abstract class, create an object from python and call
> its virtual from C++ it should not work without the default
> implementation.

The tutorial explains that well:

for the case of an abstract base, use

  def("func", bpl::pure_virtual(&Base::func))

which will provide an implementation that does nothing but raise a
Python exception to tell the caller that the method isn't implemented.

For the case with default implementation, the tutorial gives this wrapper:

  struct BaseWrap : Base, bpl::wrapper<Base>
  {
    virtual std::string func() const
    {
      if (bpl::override f = this->get_override("func"))
        return f();
      else
        return Base::func();
    }
    std::string default_func() const { return this->Base::func();}
  };

and it seems to me much more natural to implement the "default" case
directly in the "else" branch above, rather than add it to the "def()" call.

        Stefan


>
> On Mon, Aug 17, 2015 at 8:03 AM, Stefan Seefeld <stefan at seefeld.name
> <mailto:stefan at seefeld.name>> wrote:
>
>     Hi,
>
>     I'm reviewing the Boost.Python tutorial, and I'm stumbling over the
>     section on "Virtual Functions with Default implementations"
>     (http://boostorg.github.io/python/doc/html/tutorial/tutorial/exposing.html#tutorial.exposing.virtual_functions_with_default_i).
>     It mentions the need to provide a separate default implementation
>     function as third argument to "def()", without explaining why that is
>     needed.
>     In fact, I'm trying various alternatives (abstract, non-abstract),
>     and I
>     can't find a need for it. All my tests work fine without it.
>
>     Does anyone know why this is needed, and could perhaps even provide a
>     little test case ?
>
>     Thanks,
>             Stefan
>
>     --
>
>           ...ich hab' noch einen Koffer in Berlin...
>
>     _______________________________________________
>     Cplusplus-sig mailing list
>     Cplusplus-sig at python.org <mailto:Cplusplus-sig at python.org>
>     https://mail.python.org/mailman/listinfo/cplusplus-sig
>
>
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig


-- 

      ...ich hab' noch einen Koffer in Berlin...


From amohr at pixar.com  Mon Aug 17 20:54:34 2015
From: amohr at pixar.com (Alex Mohr)
Date: Mon, 17 Aug 2015 11:54:34 -0700
Subject: [C++-sig] virtual functions with default implementation
In-Reply-To: <55D22A64.6040603@seefeld.name>
References: <55D1CD77.3040708@seefeld.name>
 <CACbdn-+nea_BdVzrbpvR-nQQRPbcBrfNx3Wh7pc_bSeqBvjsHA@mail.gmail.com>
 <55D22A64.6040603@seefeld.name>
Message-ID: <55D22DEA.4000301@pixar.com>

On 8/17/2015 11:39 AM, Stefan Seefeld wrote:
> For the case with default implementation, the tutorial gives this wrapper:
>
>    struct BaseWrap : Base, bpl::wrapper<Base>
>    {
>      virtual std::string func() const
>      {
>        if (bpl::override f = this->get_override("func"))
>          return f();
>        else
>          return Base::func();
>      }
>      std::string default_func() const { return this->Base::func();}
>    };
>
> and it seems to me much more natural to implement the "default" case
> directly in the "else" branch above, rather than add it to the "def()" call.

I think this might be so that python can invoke the superclass (C++) 
implementation directly in its override, but I'm not 100% sure.

Alex


From stefan at seefeld.name  Mon Aug 17 23:44:53 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Mon, 17 Aug 2015 17:44:53 -0400
Subject: [C++-sig] virtual functions with default implementation
In-Reply-To: <55D22DEA.4000301@pixar.com>
References: <55D1CD77.3040708@seefeld.name>
 <CACbdn-+nea_BdVzrbpvR-nQQRPbcBrfNx3Wh7pc_bSeqBvjsHA@mail.gmail.com>
 <55D22A64.6040603@seefeld.name> <55D22DEA.4000301@pixar.com>
Message-ID: <55D255D5.2070807@seefeld.name>

Hi Alex,

On 17/08/15 02:54 PM, Alex Mohr wrote:
> On 8/17/2015 11:39 AM, Stefan Seefeld wrote:
>> For the case with default implementation, the tutorial gives this
>> wrapper:
>>
>>    struct BaseWrap : Base, bpl::wrapper<Base>
>>    {
>>      virtual std::string func() const
>>      {
>>        if (bpl::override f = this->get_override("func"))
>>          return f();
>>        else
>>          return Base::func();
>>      }
>>      std::string default_func() const { return this->Base::func();}
>>    };
>>
>> and it seems to me much more natural to implement the "default" case
>> directly in the "else" branch above, rather than add it to the
>> "def()" call.
>
> I think this might be so that python can invoke the superclass (C++)
> implementation directly in its override, but I'm not 100% sure.

Ah, that's it !

I just tried

Konsole output
>>> class C(Base):
...     def func(self): return super(C, self).func()

which yields an infinite recursion (until stack overflow) unless I
define "func" with the additional default function.

Thanks !

        Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...


From jeremy.murphy at biarri.com  Tue Aug 18 10:38:05 2015
From: jeremy.murphy at biarri.com (Jeremy Murphy)
Date: Tue, 18 Aug 2015 18:38:05 +1000
Subject: [C++-sig] Extracting base object reference of arbitrary Python
	object
Message-ID: <CAMJxo5PD85fQ84UkY_LLw6T9OZffbeqrAQ2NLVsDE4P1JyUP-Q@mail.gmail.com>

Hi everyone,

I have what I assume is a fairly basic or naive question, but I'm still
quite new to Boost.Python so after scouring the documentation fruitlessly I
need to turn to community wisdom.

The short version of my question is: how do I access Python Shapely
geometry in C++ using Boost.Python?

I have written an algorithm in C++ using Boost.Geometry that I wish to
export for use in Python with Shapely geometry.
Ideally, I don't want to impose any new programming overhead on the Python
side, so I wish for this algorithm to 'just work' with Shapely geometry by
using the adaptor facilities in Boost.Geometry.

Being a bit naive, what I have done so far is to create some 'proxy' C++
classes to stand for Shapely classes, e.g.:

struct Point : public boost::python::object {}
struct LinearRing : public boost::python::object {}

which I can then adapt by specializing the required traits class templates.
My algorithm in C++ looks something like:

void native_algorithm(boost::geometry::model::point const &x) {...}

void python_algorithm(boost::python::object const &x)
{
    native_algorithm(static_cast<Point const&>(x));
}

and I have this working for Point, LineString and LinearRing.

However, Polygon has brought me to my knees and challenges my whole
strategy of thinly wrapping the Shapely objects with proxy class references.
I cannot figure out how to extract (I mean boost::python::extract) a
reference to the Shapely geometry in the attributes of a Shapely Polygon.
E.g. where 'p' is a const reference to my C++ proxy Polygon class:

    extract<boost::python::object const &>(p.attr("exterior"));

I get the error:

    TypeError: No registered converter was able to extract a C++ reference
to type boost::python::api::object from this Python object of type
LinearRing

And this is where I am stuck. I just want a reference to this attribute so
that I can static_cast it to a const reference to my C++ proxy LinearRing
class. Maybe my whole approach is flawed, but if there is a way to solve
this specific glitch in my program then I think I'll be OK. I guess I'm
surprised that it does not work since the same idea of polymorphism around
the python base object class seems to work with function argument
references.
Anyway if however you recommend a completely different approach, I would be
interested in hearing that too.

Thanks, cheers.

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150818/cff292bf/attachment.html>

From stefan at seefeld.name  Tue Aug 18 23:41:15 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Tue, 18 Aug 2015 17:41:15 -0400
Subject: [C++-sig] Extracting base object reference of arbitrary Python
 object
In-Reply-To: <CAMJxo5PD85fQ84UkY_LLw6T9OZffbeqrAQ2NLVsDE4P1JyUP-Q@mail.gmail.com>
References: <CAMJxo5PD85fQ84UkY_LLw6T9OZffbeqrAQ2NLVsDE4P1JyUP-Q@mail.gmail.com>
Message-ID: <55D3A67B.6060308@seefeld.name>

Hi Jeremy,

I think you have a fundamental misunderstanding of the Boost.Python API,
so I suggest you step back a little to first get a better sense of how
the mapping between the two languages works:

On 18/08/15 04:38 AM, Jeremy Murphy wrote:
>
> struct Point : public boost::python::object {}
> struct LinearRing : public boost::python::object {}

There is really no point in deriving your own types from
boost::python::object. Instead, you should take your own (existing !)
types and embedd them into Python objects using a mechanism described in
detail in the Boost.Python tutorial:
http://boostorg.github.io/python/doc/html/tutorial/tutorial/exposing.html


>
> which I can then adapt by specializing the required traits class
> templates. My algorithm in C++ looks something like:
>
> void native_algorithm(boost::geometry::model::point const &x) {...}
>
> void python_algorithm(boost::python::object const &x)
> {
>     native_algorithm(static_cast<Point const&>(x));
> }

(I'm not entirely understand what you are trying here. Notably, what's
the relationship between the type 'Point' (which you have defined above)
and boost::geometry::model::python ?)

I suggest you start by carefully reading the tutorial referenced above,
to see how C++ objects can be embedded into (and extracted from) Python
objects.
That may not yet answer all your questions, but I'm convinced that once
you understand the techniques described there, you will ask
fundamentally different questions, which I'll gladly try to answer. :-)

Regards,
        Stefan



-- 

      ...ich hab' noch einen Koffer in Berlin...


From finjulhich at gmail.com  Fri Aug 28 13:49:53 2015
From: finjulhich at gmail.com (MM)
Date: Fri, 28 Aug 2015 12:49:53 +0100
Subject: [C++-sig] register c++ std::pair<string,
	string> and std::pair<string*, string*>
Message-ID: <CADsB1iDYtcj2wBtyO-5F19h65yYFg_cWfP4c7xUvTDhB3kpRnQ@mail.gmail.com>

I expose the return type of a C++ function that is a pair of strings with
the following snippet:

to_python_converter<
    std::pair<std::string, std::string>,
    Converter>();

Later, I have a unrelated C++ range type:

typedef std::pair<const std::string*,const std::string*> range_t;

which I export as:

class_<range_t>("range")
    .def("__iter__" , range(..., ...));
scope().attr("allitems") = object(ptr(&R));

where R is of type range_t

in python, allitems can be iterated over.

The only issue is I get the following warning:

/usr/lib64/python3.4/importlib/_bootstrap.py:321: RuntimeWarning:
to-Python converter for std::pair<std::string const*, std::string
const*> already registered; second conversion method ignored.

Is there a way to avoid this warning?

MM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150828/b3a7004e/attachment.html>

From stefan at seefeld.name  Fri Aug 28 14:41:31 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Fri, 28 Aug 2015 08:41:31 -0400
Subject: [C++-sig] register c++ std::pair<string,
 string> and std::pair<string*, string*>
In-Reply-To: <CADsB1iDYtcj2wBtyO-5F19h65yYFg_cWfP4c7xUvTDhB3kpRnQ@mail.gmail.com>
References: <CADsB1iDYtcj2wBtyO-5F19h65yYFg_cWfP4c7xUvTDhB3kpRnQ@mail.gmail.com>
Message-ID: <55E056FB.504@seefeld.name>

On 28/08/15 07:49 AM, MM wrote:
>
> I expose the return type of a C++ function that is a pair of strings
> with the following snippet:
>
> |to_python_converter<std::pair<std::string,std::string>,Converter>();|
>
> Later, I have a unrelated C++ range type:
>
> |typedef std::pair<const std::string*,const std::string*>range_t;|
>
> which I export as:
>
> |class_<range_t>("range").def("__iter__",range(...,...));scope().attr("allitems")=object(ptr(&R));|
>
> where R is of type range_t
>
> in python, allitems can be iterated over.
>
> The only issue is I get the following warning:
>
> |/usr/lib64/python3.4/importlib/_bootstrap.py:321:RuntimeWarning:to-Pythonconverter
> forstd::pair<std::string const*,std::string const*>already
> registered;second conversion method ignored.|
>
> Is there a way to avoid this warning?
>

Why do you need the explicit converter if you also define a
class_<range_t> ? Wouldn't everything work just fine without it ?

        Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From finjulhich at gmail.com  Fri Aug 28 15:26:53 2015
From: finjulhich at gmail.com (MM)
Date: Fri, 28 Aug 2015 14:26:53 +0100
Subject: [C++-sig] register c++ std::pair<string,
 string> and std::pair<string*, string*>
In-Reply-To: <55E056FB.504@seefeld.name>
References: <CADsB1iDYtcj2wBtyO-5F19h65yYFg_cWfP4c7xUvTDhB3kpRnQ@mail.gmail.com>
 <55E056FB.504@seefeld.name>
Message-ID: <CADsB1iAgUzGNSKkaEJGz1561+3-r7EL-tv0o8S8ByjNffKDpUA@mail.gmail.com>

On 28 August 2015 at 13:41, Stefan Seefeld <stefan at seefeld.name> wrote:

> On 28/08/15 07:49 AM, MM wrote:
> >
> > I expose the return type of a C++ function that is a pair of strings
> > with the following snippet:
> >
> > |to_python_converter<std::pair<std::string,std::string>,Converter>();|
> >
> > Later, I have a unrelated C++ range type:
> >
> > |typedef std::pair<const std::string*,const std::string*>range_t;|
> >
> > which I export as:
> >
> >
> |class_<range_t>("range").def("__iter__",range(...,...));scope().attr("allitems")=object(ptr(&R));|
> >
> > where R is of type range_t
> >
> > in python, allitems can be iterated over.
> >
> > The only issue is I get the following warning:
> >
> >
> |/usr/lib64/python3.4/importlib/_bootstrap.py:321:RuntimeWarning:to-Pythonconverter
> > forstd::pair<std::string const*,std::string const*>already
> > registered;second conversion method ignored.|
> >
> > Is there a way to avoid this warning?
> >
>
> Why do you need the explicit converter if you also define a
> class_<range_t> ? Wouldn't everything work just fine without it ?
>
>         Stefan
>
This is in too separate modules.
The converter is registered in module1, and the class_<range_t> in module 2.
I import 1 then 2, then it happens

Also the intents are different. THe pair<string,string> is to be considered
as a (str1,str2) tuple of 2 values.
The pair<string*, string*> is the [begin, end[ iterators into an array with
value_type string
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150828/2b0b6437/attachment-0001.html>

From stefan at seefeld.name  Fri Aug 28 16:01:18 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Fri, 28 Aug 2015 10:01:18 -0400
Subject: [C++-sig] register c++ std::pair<string,
 string> and std::pair<string*, string*>
In-Reply-To: <CADsB1iAgUzGNSKkaEJGz1561+3-r7EL-tv0o8S8ByjNffKDpUA@mail.gmail.com>
References: <CADsB1iDYtcj2wBtyO-5F19h65yYFg_cWfP4c7xUvTDhB3kpRnQ@mail.gmail.com>
 <55E056FB.504@seefeld.name>
 <CADsB1iAgUzGNSKkaEJGz1561+3-r7EL-tv0o8S8ByjNffKDpUA@mail.gmail.com>
Message-ID: <55E069AE.6030909@seefeld.name>

On 28/08/15 09:26 AM, MM wrote:
> This is in too separate modules.
> The converter is registered in module1, and the class_<range_t> in
> module 2.
> I import 1 then 2, then it happens
>
> Also the intents are different. THe pair<string,string> is to be
> considered as a (str1,str2) tuple of 2 values.
> The pair<string*, string*> is the [begin, end[ iterators into an array
> with value_type string


Oups, sorry, I hadn't noticed that they had different types. Can you
please post a minimal bug self-contained test case ? I'd like to debug
this a bit to better understand what is going on. I believe this should
work as there is no reason the two types should be confused. (It
obviously depends on your "Converter" type, which you haven't shown.)

Thanks,
    Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...


From finjulhich at gmail.com  Fri Aug 28 16:15:50 2015
From: finjulhich at gmail.com (MM)
Date: Fri, 28 Aug 2015 15:15:50 +0100
Subject: [C++-sig] register c++ std::pair<string,
 string> and std::pair<string*, string*>
In-Reply-To: <55E069AE.6030909@seefeld.name>
References: <CADsB1iDYtcj2wBtyO-5F19h65yYFg_cWfP4c7xUvTDhB3kpRnQ@mail.gmail.com>
 <55E056FB.504@seefeld.name>
 <CADsB1iAgUzGNSKkaEJGz1561+3-r7EL-tv0o8S8ByjNffKDpUA@mail.gmail.com>
 <55E069AE.6030909@seefeld.name>
Message-ID: <CADsB1iAGoNe3R7xVZRMpxCUR1cWzChsBGT=ye1P-miKwGJqsUA@mail.gmail.com>

On 28 August 2015 at 15:01, Stefan Seefeld <stefan at seefeld.name> wrote:

> On 28/08/15 09:26 AM, MM wrote:
> > This is in too separate modules.
> > The converter is registered in module1, and the class_<range_t> in
> > module 2.
> > I import 1 then 2, then it happens
> >
> > Also the intents are different. THe pair<string,string> is to be
> > considered as a (str1,str2) tuple of 2 values.
> > The pair<string*, string*> is the [begin, end[ iterators into an array
> > with value_type string
>
>
> Oups, sorry, I hadn't noticed that they had different types. Can you
> please post a minimal bug self-contained test case ? I'd like to debug
> this a bit to better understand what is going on. I believe this should
> work as there is no reason the two types should be confused. (It
> obviously depends on your "Converter" type, which you haven't shown.)
>
> Thanks,
>     Stefan
>
>
Well, there's something about the fact that pointer types somehow change to
the types pointed to.... I don't understand it well

I tried to strip it down here:

/// header file
template <typename T1, typename T2>
struct stdpair_to_python_tuple
{
  static PyObject* convert(const std::pair<T1,T2>&pr)
  {
    return incref( make_tuple(pr.first, pr.second).ptr() );
  }
};

/// module1.cpp
BOOST_PYTHON_MODULE(libmodule1)
{
  to_python_converter<
      std::pair<std::string, std::string>,
      stdpair_to_python_tuple<std::string,std::string>>();
}

/// module2.cpp
typedef std::pair<const std::string*,const std::string*> range_t;
range_t range;

BOOST_PYTHON_MODULE(libmodule2)
{
  using namespace boost::python;

  class_<range_t>("range")
    .def("__iter__",
  range(&range_t::first, &range_t::second))
    ;

  scope().attr("allitems") = object(ptr(&range));
}


Load 1 then 2 it should trigger the warning.
Apologies for missing the includes.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150828/fe8ad2b8/attachment.html>

From stefan at seefeld.name  Fri Aug 28 16:20:22 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Fri, 28 Aug 2015 10:20:22 -0400
Subject: [C++-sig] register c++ std::pair<string,
 string> and std::pair<string*, string*>
In-Reply-To: <CADsB1iAGoNe3R7xVZRMpxCUR1cWzChsBGT=ye1P-miKwGJqsUA@mail.gmail.com>
References: <CADsB1iDYtcj2wBtyO-5F19h65yYFg_cWfP4c7xUvTDhB3kpRnQ@mail.gmail.com>
 <55E056FB.504@seefeld.name>
 <CADsB1iAgUzGNSKkaEJGz1561+3-r7EL-tv0o8S8ByjNffKDpUA@mail.gmail.com>
 <55E069AE.6030909@seefeld.name>
 <CADsB1iAGoNe3R7xVZRMpxCUR1cWzChsBGT=ye1P-miKwGJqsUA@mail.gmail.com>
Message-ID: <55E06E26.8030100@seefeld.name>

On 28/08/15 10:15 AM, MM wrote:
>
>
> On 28 August 2015 at 15:01, Stefan Seefeld <stefan at seefeld.name
> <mailto:stefan at seefeld.name>> wrote:
>
>     On 28/08/15 09:26 AM, MM wrote:
>     > This is in too separate modules.
>     > The converter is registered in module1, and the class_<range_t> in
>     > module 2.
>     > I import 1 then 2, then it happens
>     >
>     > Also the intents are different. THe pair<string,string> is to be
>     > considered as a (str1,str2) tuple of 2 values.
>     > The pair<string*, string*> is the [begin, end[ iterators into an
>     array
>     > with value_type string
>
>
>     Oups, sorry, I hadn't noticed that they had different types. Can you
>     please post a minimal bug self-contained test case ? I'd like to debug
>     this a bit to better understand what is going on. I believe this
>     should
>     work as there is no reason the two types should be confused. (It
>     obviously depends on your "Converter" type, which you haven't shown.)
>
>     Thanks,
>         Stefan
>      
>
> Well, there's something about the fact that pointer types somehow
> change to the types pointed to.... I don't understand it well

Yes, sure: by default, if you pass a pointer-to-A to Python, it will
actually pass the A, unless you use the 'ptr()' wrapper. But that
doesn't mean a container-to-A and container-to-pointer-to-A should be
confused...

I'll look at your sample code, thank.
        Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...


From stefan at seefeld.name  Fri Aug 28 17:05:34 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Fri, 28 Aug 2015 11:05:34 -0400
Subject: [C++-sig] register c++ std::pair<string,
 string> and std::pair<string*, string*>
In-Reply-To: <CADsB1iAGoNe3R7xVZRMpxCUR1cWzChsBGT=ye1P-miKwGJqsUA@mail.gmail.com>
References: <CADsB1iDYtcj2wBtyO-5F19h65yYFg_cWfP4c7xUvTDhB3kpRnQ@mail.gmail.com>
 <55E056FB.504@seefeld.name>
 <CADsB1iAgUzGNSKkaEJGz1561+3-r7EL-tv0o8S8ByjNffKDpUA@mail.gmail.com>
 <55E069AE.6030909@seefeld.name>
 <CADsB1iAGoNe3R7xVZRMpxCUR1cWzChsBGT=ye1P-miKwGJqsUA@mail.gmail.com>
Message-ID: <55E078BE.40006@seefeld.name>

On 28/08/15 10:15 AM, MM wrote:
>
> Load 1 then 2 it should trigger the warning. 
> Apologies for missing the includes.

I had to modify your code a bit as it triggers errors when compiled
as-is. And with those modifications it didn't see any warning.
Could you please post code that I can compile without any modifications ?

Thanks,
        Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...


From finjulhich at gmail.com  Fri Aug 28 17:41:03 2015
From: finjulhich at gmail.com (MM)
Date: Fri, 28 Aug 2015 16:41:03 +0100
Subject: [C++-sig] register c++ std::pair<string,
 string> and std::pair<string*, string*>
In-Reply-To: <55E078BE.40006@seefeld.name>
References: <CADsB1iDYtcj2wBtyO-5F19h65yYFg_cWfP4c7xUvTDhB3kpRnQ@mail.gmail.com>
 <55E056FB.504@seefeld.name>
 <CADsB1iAgUzGNSKkaEJGz1561+3-r7EL-tv0o8S8ByjNffKDpUA@mail.gmail.com>
 <55E069AE.6030909@seefeld.name>
 <CADsB1iAGoNe3R7xVZRMpxCUR1cWzChsBGT=ye1P-miKwGJqsUA@mail.gmail.com>
 <55E078BE.40006@seefeld.name>
Message-ID: <CADsB1iAdfrgZ_fmWqQwoRpPkBfrvgrBpy93Md3qgpD1jisULhw@mail.gmail.com>

On 28 August 2015 at 16:05, Stefan Seefeld <stefan at seefeld.name> wrote:

> On 28/08/15 10:15 AM, MM wrote:
> >
> > Load 1 then 2 it should trigger the warning.
> > Apologies for missing the includes.
>
> I had to modify your code a bit as it triggers errors when compiled
> as-is. And with those modifications it didn't see any warning.
> Could you please post code that I can compile without any modifications ?
>
> Thanks,
>         Stefan
>

Apologies, I also didn't get any warnings.

I was actually registering an identical   std::pair<const string*, const
string*> as an iterator with a different name in a prior module, ie I had
another class_<range2_t>("range2")

and range2_t is identical to ranget_t :-)

Thanks for helping to spot this:-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150828/30b28a42/attachment-0001.html>

From stefan at seefeld.name  Fri Aug 28 17:42:55 2015
From: stefan at seefeld.name (Stefan Seefeld)
Date: Fri, 28 Aug 2015 11:42:55 -0400
Subject: [C++-sig] register c++ std::pair<string,
 string> and std::pair<string*, string*>
In-Reply-To: <CADsB1iAdfrgZ_fmWqQwoRpPkBfrvgrBpy93Md3qgpD1jisULhw@mail.gmail.com>
References: <CADsB1iDYtcj2wBtyO-5F19h65yYFg_cWfP4c7xUvTDhB3kpRnQ@mail.gmail.com>
 <55E056FB.504@seefeld.name>
 <CADsB1iAgUzGNSKkaEJGz1561+3-r7EL-tv0o8S8ByjNffKDpUA@mail.gmail.com>
 <55E069AE.6030909@seefeld.name>
 <CADsB1iAGoNe3R7xVZRMpxCUR1cWzChsBGT=ye1P-miKwGJqsUA@mail.gmail.com>
 <55E078BE.40006@seefeld.name>
 <CADsB1iAdfrgZ_fmWqQwoRpPkBfrvgrBpy93Md3qgpD1jisULhw@mail.gmail.com>
Message-ID: <55E0817F.4050409@seefeld.name>

On 28/08/15 11:41 AM, MM wrote:
> On 28 August 2015 at 16:05, Stefan Seefeld <stefan at seefeld.name
> <mailto:stefan at seefeld.name>> wrote:
>
>     On 28/08/15 10:15 AM, MM wrote:
>     >
>     > Load 1 then 2 it should trigger the warning.
>     > Apologies for missing the includes.
>
>     I had to modify your code a bit as it triggers errors when compiled
>     as-is. And with those modifications it didn't see any warning.
>     Could you please post code that I can compile without any
>     modifications ?
>
>     Thanks,
>             Stefan
>
>
> Apologies, I also didn't get any warnings.
>
> I was actually registering an identical   std::pair<const string*,
> const string*> as an iterator with a different name in a prior module,
> ie I had another class_<range2_t>("range2")
>
> and range2_t is identical to ranget_t :-)

Aha ! Yeah, that's clearly not going to work due to the ambiguity.


>
> Thanks for helping to spot this:-)

Welcome !:-)

        Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...