From sunfish7 at gmail.com  Wed Oct  1 13:28:17 2014
From: sunfish7 at gmail.com (pi)
Date: Wed, 1 Oct 2014 04:28:17 -0700 (PDT)
Subject: [C++-sig] boost::python embedding error - runtime - Mac OS X -
	1.38
In-Reply-To: <88575950903051047p6fe2ec9bo178fbc40d18a1d72@mail.gmail.com>
References: <88575950903051047p6fe2ec9bo178fbc40d18a1d72@mail.gmail.com>
Message-ID: <1412162897159-4668060.post@n4.nabble.com>

Was this problem ever resolved?  I am getting exactly the same issue on OSX
Mavericks.  I create a new Xcode commandline project, link libpython3.4.1
and libboost_python dylibs, add relevant header-search-paths.

Then I modify main.c to:

    #include <boost/python.hpp>

    int main( int argc, const char* argv[] )
    {
        Py_Initialize();    
        using namespace boost::python;    
        object main_module = import("__main__"); // <--
EXC_BAD_ACCESS(code=1, address=0x0)
    }

In fact everything below the error can be removed, giving a minimal failure
example.



--
View this message in context: http://boost.2283326.n4.nabble.com/boost-python-embedding-error-runtime-Mac-OS-X-1-38-tp2702075p4668060.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.

From finjulhich at gmail.com  Thu Oct  2 22:09:20 2014
From: finjulhich at gmail.com (MM)
Date: Thu, 2 Oct 2014 21:09:20 +0100
Subject: [C++-sig] boost python class member getter/setter same name
	different only by constness
Message-ID: <CADsB1iBk4-cyaMBxWF0QVvwKWW745fsEpOw3qstyBk+h6mmPRw@mail.gmail.com>

Hi

class C {
public:
  const std::string& name() const;
  std::string& name();
private:
  std::string name_;
};

given this class C, how would I expose it to python with the class property
name?

class_<C>("C").
  .add_property("name",   &C::name, &C::name);

or do I use 2 mem function pointers to distinguish the 2 names, and pass
those 2 pointers?

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

From stefan at seefeld.name  Fri Oct  3 18:50:33 2014
From: stefan at seefeld.name (Stefan Seefeld)
Date: Fri, 03 Oct 2014 12:50:33 -0400
Subject: [C++-sig] boost python class member getter/setter same name
 different only by constness
In-Reply-To: <CADsB1iBk4-cyaMBxWF0QVvwKWW745fsEpOw3qstyBk+h6mmPRw@mail.gmail.com>
References: <CADsB1iBk4-cyaMBxWF0QVvwKWW745fsEpOw3qstyBk+h6mmPRw@mail.gmail.com>
Message-ID: <542ED3D9.7080004@seefeld.name>

On 2014-10-02 16:09, MM wrote:
> Hi
>
> class C {
> public:
>   const std::string& name() const;
>   std::string& name();
> private:
>   std::string name_;
> };
>
> given this class C, how would I expose it to python with the class
> property name?
>
> class_<C>("C").
>   .add_property("name",   &C::name, &C::name);
>
> or do I use 2 mem function pointers to distinguish the 2 names, and
> pass those 2 pointers?

You need to disambiguate the two overloads. The cleanest way to do that
is to introduce two (local) variables of the appropriate
pointer-to-member-function types, then pass those variables to the
'add_property' call.
In addition, I believe boost.python expects a different signature for
the setter (a function taking a value-type argument), so you may have to
provide a wrapper function for that, unless you want to modify the 'C'
class in-place.

HTH,
        Stefan



-- 

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


From finjulhich at gmail.com  Fri Oct  3 18:56:12 2014
From: finjulhich at gmail.com (MM)
Date: Fri, 3 Oct 2014 17:56:12 +0100
Subject: [C++-sig] boost python class member getter/setter same name
 different only by constness
In-Reply-To: <542ED3D9.7080004@seefeld.name>
References: <CADsB1iBk4-cyaMBxWF0QVvwKWW745fsEpOw3qstyBk+h6mmPRw@mail.gmail.com>
 <542ED3D9.7080004@seefeld.name>
Message-ID: <CADsB1iDrvcT9VM-Q8Ro9tYpNLnQ7gQs5r-P--34qFrrd2d0Owg@mail.gmail.com>

yes i did that.

class C {
> public:
>   const std::string& get_name() const;
>   void set_name(const std::string&);
> private:
>   std::string name_;
> };
>


> class_<C>("C").
>   .add_property("name",   &C::get_name, &C::set_name);


this fails to compile because of unspecified call policies about the string
refs.


The following, on the other hand, compiles.

> class C {
> public:
>   const std::string get_name() const;
>   void set_name(const std::string);
> ....
> class_<C>("C").
>   .add_property("name",   &C::get_name, &C::set_name);


Which policy do I specify? and how do I set it in add_property?

MM

On 3 October 2014 17:50, Stefan Seefeld <stefan at seefeld.name> wrote:

> On 2014-10-02 16:09, MM wrote:
> > Hi
> >
> > class C {
> > public:
> >   const std::string& name() const;
> >   std::string& name();
> > private:
> >   std::string name_;
> > };
> >
> > given this class C, how would I expose it to python with the class
> > property name?
> >
> > class_<C>("C").
> >   .add_property("name",   &C::name, &C::name);
> >
> > or do I use 2 mem function pointers to distinguish the 2 names, and
> > pass those 2 pointers?
>
> You need to disambiguate the two overloads. The cleanest way to do that
> is to introduce two (local) variables of the appropriate
> pointer-to-member-function types, then pass those variables to the
> 'add_property' call.
> In addition, I believe boost.python expects a different signature for
> the setter (a function taking a value-type argument), so you may have to
> provide a wrapper function for that, unless you want to modify the 'C'
> class in-place.
>
> HTH,
>         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/20141003/34c548c0/attachment.html>

From stefan at seefeld.name  Fri Oct  3 19:15:44 2014
From: stefan at seefeld.name (Stefan Seefeld)
Date: Fri, 03 Oct 2014 13:15:44 -0400
Subject: [C++-sig] boost python class member getter/setter same name
 different only by constness
In-Reply-To: <CADsB1iDrvcT9VM-Q8Ro9tYpNLnQ7gQs5r-P--34qFrrd2d0Owg@mail.gmail.com>
References: <CADsB1iBk4-cyaMBxWF0QVvwKWW745fsEpOw3qstyBk+h6mmPRw@mail.gmail.com>
 <542ED3D9.7080004@seefeld.name>
 <CADsB1iDrvcT9VM-Q8Ro9tYpNLnQ7gQs5r-P--34qFrrd2d0Owg@mail.gmail.com>
Message-ID: <542ED9C0.8070808@seefeld.name>

On 2014-10-03 12:56, MM wrote:
> yes i did that.
>
>     class C {
>     public:
>       const std::string& get_name() const;
>       void set_name(const std::string&);
>     private:
>       std::string name_;
>     };
>
>  
>
>     class_<C>("C").
>       .add_property("name",   &C::get_name, &C::set_name);
>
>
> this fails to compile because of unspecified call policies about the
> string refs.
>
>
> The following, on the other hand, compiles.
>
>     class C {
>     public:
>       const std::string get_name() const;
>       void set_name(const std::string);
>     ....
>     class_<C>("C").
>       .add_property("name",   &C::get_name, &C::set_name);
>
>
> Which policy do I specify? and how do I set it in add_property?

Good question. The policy you want is likely pass-by-value (In Python
strings are immutable anyhow), however I have no idea how to express
that with the add_property() call.
As a quick hack I suggest adding a wrapper function that returns the
result by-value:

  std::string get_name(C &c) { return c.get_name();}

and use that. That's neither elegant nor efficient (if you call it a
lot), but it may unblock you until you find a real fix.

    Stefan

-- 

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


From talljimbo at gmail.com  Fri Oct  3 19:23:33 2014
From: talljimbo at gmail.com (Jim Bosch)
Date: Fri, 3 Oct 2014 13:23:33 -0400
Subject: [C++-sig] boost python class member getter/setter same name
 different only by constness
In-Reply-To: <542ED9C0.8070808@seefeld.name>
References: <CADsB1iBk4-cyaMBxWF0QVvwKWW745fsEpOw3qstyBk+h6mmPRw@mail.gmail.com>
 <542ED3D9.7080004@seefeld.name>
 <CADsB1iDrvcT9VM-Q8Ro9tYpNLnQ7gQs5r-P--34qFrrd2d0Owg@mail.gmail.com>
 <542ED9C0.8070808@seefeld.name>
Message-ID: <CAN+0q27-5qYUjx4MMs5swy3NNgQdrOwnpEys0YOnH5iLcF1qXg@mail.gmail.com>

On Fri, Oct 3, 2014 at 1:15 PM, Stefan Seefeld <stefan at seefeld.name> wrote:

> On 2014-10-03 12:56, MM wrote:
> > yes i did that.
> >
> >     class C {
> >     public:
> >       const std::string& get_name() const;
> >       void set_name(const std::string&);
> >     private:
> >       std::string name_;
> >     };
> >
> >
> >
> >     class_<C>("C").
> >       .add_property("name",   &C::get_name, &C::set_name);
> >
> >
> > this fails to compile because of unspecified call policies about the
> > string refs.
> >
> >
> > The following, on the other hand, compiles.
> >
> >     class C {
> >     public:
> >       const std::string get_name() const;
> >       void set_name(const std::string);
> >     ....
> >     class_<C>("C").
> >       .add_property("name",   &C::get_name, &C::set_name);
> >
> >
> > Which policy do I specify? and how do I set it in add_property?
>
> Good question. The policy you want is likely pass-by-value (In Python
> strings are immutable anyhow), however I have no idea how to express
> that with the add_property() call.
> As a quick hack I suggest adding a wrapper function that returns the
> result by-value:
>
>   std::string get_name(C &c) { return c.get_name();}
>
> and use that. That's neither elegant nor efficient (if you call it a
> lot), but it may unblock you until you find a real fix.
>
>
To use a call policy here, I *think* you'd pass
return_value_policy<return_by_value>() as the fourth argument to
add_property, but it may be some slight modification of that.  In any case,
I suspect that's no more efficient than Stefan's solution in this case.


Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20141003/5811bdb7/attachment-0001.html>

From finjulhich at gmail.com  Fri Oct  3 20:11:26 2014
From: finjulhich at gmail.com (MM)
Date: Fri, 3 Oct 2014 19:11:26 +0100
Subject: [C++-sig] boost python class member getter/setter same name
 different only by constness
In-Reply-To: <CAN+0q27-5qYUjx4MMs5swy3NNgQdrOwnpEys0YOnH5iLcF1qXg@mail.gmail.com>
References: <CADsB1iBk4-cyaMBxWF0QVvwKWW745fsEpOw3qstyBk+h6mmPRw@mail.gmail.com>
 <542ED3D9.7080004@seefeld.name>
 <CADsB1iDrvcT9VM-Q8Ro9tYpNLnQ7gQs5r-P--34qFrrd2d0Owg@mail.gmail.com>
 <542ED9C0.8070808@seefeld.name>
 <CAN+0q27-5qYUjx4MMs5swy3NNgQdrOwnpEys0YOnH5iLcF1qXg@mail.gmail.com>
Message-ID: <CADsB1iDo8z0TNXyHnEca+CkyRQvpruuQW=S9+5SVbpm7nRyu8w@mail.gmail.com>

On 3 October 2014 18:23, Jim Bosch <talljimbo at gmail.com> wrote:

> On Fri, Oct 3, 2014 at 1:15 PM, Stefan Seefeld <stefan at seefeld.name>
> wrote:
>
>> On 2014-10-03 12:56, MM wrote:
>> > yes i did that.
>> >
>> >     class C {
>> >     public:
>> >       const std::string& get_name() const;
>> >       void set_name(const std::string&);
>> >     private:
>> >       std::string name_;
>> >     };
>> >
>> >
>> >
>> >     class_<C>("C").
>> >       .add_property("name",   &C::get_name, &C::set_name);
>> >
>> >
>> > this fails to compile because of unspecified call policies about the
>> > string refs.
>> >
>> >
>> > The following, on the other hand, compiles.
>> >
>> >     class C {
>> >     public:
>> >       const std::string get_name() const;
>> >       void set_name(const std::string);
>> >     ....
>> >     class_<C>("C").
>> >       .add_property("name",   &C::get_name, &C::set_name);
>> >
>> >
>> > Which policy do I specify? and how do I set it in add_property?
>>
>> Good question. The policy you want is likely pass-by-value (In Python
>> strings are immutable anyhow), however I have no idea how to express
>> that with the add_property() call.
>> As a quick hack I suggest adding a wrapper function that returns the
>> result by-value:
>>
>>   std::string get_name(C &c) { return c.get_name();}
>>
>> and use that. That's neither elegant nor efficient (if you call it a
>> lot), but it may unblock you until you find a real fix.
>>
>>
> To use a call policy here, I *think* you'd pass
> return_value_policy<return_by_value>() as the fourth argument to
> add_property, but it may be some slight modification of that.  In any case,
> I suspect that's no more efficient than Stefan's solution in this case.
>
>
> Jim
>
> Not quite. get_property's 4th argument is just a docstring.
It seems only def has a policy argument.

Actually this is a problem because the next 2 properties of the class are
big vectors.

I am gonna go with just defs of getter/setter instead as add_property
doesn't help (i looked at class.hpp inside boost.python)

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

From eugen.wintersberger at desy.de  Wed Oct 22 14:08:24 2014
From: eugen.wintersberger at desy.de (Wintersberger, Eugen)
Date: Wed, 22 Oct 2014 14:08:24 +0200
Subject: [C++-sig] sharing code between different python extensions
Message-ID: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>

Hi there
  I have a little problem with two Python extensions (C++ with
boost::python) where share code. An example of what I am trying to do is
attached to this mail so I will refer to the code in the tarball to
explain the problem. 

I have to Python extensions ('a' and 'b') each of them exporting two
functions. What I want is to use a function exported by 'a' in the code
of 'b'. Though the package compiles I get an unresolved symbol error
when trying to load 'b'. 

The reason is quite clear. 'b' cannot resolve the symbol as it is
provided by 'a' to which it is not linked. Is it somehow possible with
distutils to link the two extensions to that 'b' can see the symbols
provided by 'a'?

best regards
  Eugen Wintersberger 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boost_python_extensions.tar.gz
Type: application/x-compressed-tar
Size: 1016 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20141022/1a709aa2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20141022/1a709aa2/attachment.sig>

From nat at lindenlab.com  Thu Oct 23 14:11:12 2014
From: nat at lindenlab.com (Nat Goodspeed)
Date: Thu, 23 Oct 2014 08:11:12 -0400
Subject: [C++-sig] sharing code between different python extensions
In-Reply-To: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>
References: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>
Message-ID: <AE55D13E-5886-4F5B-8FAD-633AC1D40CBF@lindenlab.com>

On Oct 22, 2014, at 8:08 AM, "Wintersberger, Eugen" <eugen.wintersberger at desy.de> wrote:

>  I have a little problem with two Python extensions (C++ with
> boost::python) where share code. 
> 
> I have to Python extensions ('a' and 'b') each of them exporting two
> functions. What I want is to use a function exported by 'a' in the code
> of 'b'. Though the package compiles I get an unresolved symbol error
> when trying to load 'b'. 

If I were faced with this situation either in pure Python, or pure C++, I would probably break out module 'c' with functions consumed by both 'a' and 'b'.

Could this work in your situation?
> 

From stefan at seefeld.name  Thu Oct 23 15:50:11 2014
From: stefan at seefeld.name (Stefan Seefeld)
Date: Thu, 23 Oct 2014 09:50:11 -0400
Subject: [C++-sig] sharing code between different python extensions
In-Reply-To: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>
References: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>
Message-ID: <54490793.9030009@seefeld.name>

On 22/10/14 08:08 AM, Wintersberger, Eugen wrote:
> Hi there
>   I have a little problem with two Python extensions (C++ with
> boost::python) where share code. An example of what I am trying to do is
> attached to this mail so I will refer to the code in the tarball to
> explain the problem. 
>
> I have to Python extensions ('a' and 'b') each of them exporting two
> functions. What I want is to use a function exported by 'a' in the code
> of 'b'. Though the package compiles I get an unresolved symbol error
> when trying to load 'b'. 
>
> The reason is quite clear. 'b' cannot resolve the symbol as it is
> provided by 'a' to which it is not linked. Is it somehow possible with
> distutils to link the two extensions to that 'b' can see the symbols
> provided by 'a'?

Python extension modules may not depend on each other in that way.
(Arguably that is a Good Thing, as it avoids possible ABI compatibility
issues.)
What I suggest you do is either refactor the code such that your
extensions 'a' and 'b' both link to a shared library 'c' which provides
the symbols used by both. Alternatively you could try to reduce the
dependency to only exist at the Python interface level, such that using
'b' requires 'a' being loaded (for example to enable type converters
defined in 'a' but used in 'b'), but without any direct ABI dependencies
between 'a' and 'b'.

         Stefan



-- 

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


From etuerke at googlemail.com  Thu Oct 23 09:38:07 2014
From: etuerke at googlemail.com (=?UTF-8?Q?Erik_T=C3=BCrke?=)
Date: Thu, 23 Oct 2014 09:38:07 +0200
Subject: [C++-sig] Exposing simple polymorphism with boost python
Message-ID: <CAEWxakKUy6iCQ1ZfxLpoi=VFzSRyTbaBMyjpMvCjiJqgKAHsCg@mail.gmail.com>

Hi Python-Experts :-)


i am starting to get really frustrated trying to expose a simple C++
polymorphism to python with boost::python.
I do have the following structure in C++:

    struct Base {
        int typeID;
    };

    struct Derived : public Base {
        int derivedProperty;
    }

    //and some more from base derived types....

    Base *returnSomethingDerivedFromBase(...) {
        Derived *ret = new Derived;
        ret->derivedProperty = 1234;
        return ret;
    }

    BOOST_PYTHON_MODULE(foo)
    {
        class_<Base>("Base")
            .add_property("baseProperty", &Base::baseProperty);

        class_<Derived, bases<Base> >("Derived")
            .add_property("derivedProperty", &Derived::derivedProperty);

        def("returnSomethingDerivedFromBase",
returnSomethingDerivedFromBase);
    }


And in Python i just want to have the following:

    object = returnSomethingFromDerived() #object is of type Base
    if object.typeID = 1:
        #here i want to cast to Derived and access "derivedProperty"
        #but this is not working :-( :
        object.__class__ = Derived

Is there a way to accomplish this at all? Or isn?t this possible as it
would be in C++ ?

Thanks a lot for your help!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20141023/e4ac7d40/attachment-0001.html>

From eugen.wintersberger at desy.de  Thu Oct 23 15:47:55 2014
From: eugen.wintersberger at desy.de (Wintersberger, Eugen)
Date: Thu, 23 Oct 2014 15:47:55 +0200
Subject: [C++-sig] sharing code between different python extensions
In-Reply-To: <AE55D13E-5886-4F5B-8FAD-633AC1D40CBF@lindenlab.com>
References: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>
 <AE55D13E-5886-4F5B-8FAD-633AC1D40CBF@lindenlab.com>
Message-ID: <35E004AD6290A7438FCA34BBF325F41606996A78@ADXV2.win.desy.de>

Hi

On Thu, 2014-10-23 at 08:11 -0400, Nat Goodspeed wrote:
> On Oct 22, 2014, at 8:08 AM, "Wintersberger, Eugen" <eugen.wintersberger at desy.de> wrote:
> 
> >  I have a little problem with two Python extensions (C++ with
> > boost::python) where share code. 
> > 
> > I have to Python extensions ('a' and 'b') each of them exporting two
> > functions. What I want is to use a function exported by 'a' in the code
> > of 'b'. Though the package compiles I get an unresolved symbol error
> > when trying to load 'b'. 
> 
> If I were faced with this situation either in pure Python, or pure C++, I would probably break out module 'c' with functions consumed by both 'a' and 'b'.
> Could this work in your situation?

This approach would not really help me. I guess what I really need is
something like the numpy approach: a way to export the API of an
extension to other extensions. But I have no idea how to do this ;)?

Are there any reference you can suggest which I should read if I want to
follow this approach?

regards
  Eugen

> > 
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20141023/aa1f15cf/attachment-0001.sig>

From eugen.wintersberger at desy.de  Thu Oct 23 16:33:48 2014
From: eugen.wintersberger at desy.de (Wintersberger, Eugen)
Date: Thu, 23 Oct 2014 16:33:48 +0200
Subject: [C++-sig] sharing code between different python extensions
In-Reply-To: <54490793.9030009@seefeld.name>
References: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>
 <54490793.9030009@seefeld.name>
Message-ID: <35E004AD6290A7438FCA34BBF325F41606996A7B@ADXV2.win.desy.de>

Hi Stefan
  
> Python extension modules may not depend on each other in that way.
> (Arguably that is a Good Thing, as it avoids possible ABI compatibility
> issues.)
> What I suggest you do is either refactor the code such that your
> extensions 'a' and 'b' both link to a shared library 'c' which provides
> the symbols used by both. 

If the real problem would be as in the example I would definitely go
with this approach (I even tried to do so). However, the real problem is
more complex. The functions in 'a' call Python API and numpy API
functions. Thus, when distutils builds the code it does this according
to a particular Python version. So building a single shared library
would not help too much. 

> Alternatively you could try to reduce the
> dependency to only exist at the Python interface level, such that using
> 'b' requires 'a' being loaded (for example to enable type converters
> defined in 'a' but used in 'b'), but without any direct ABI dependencies
> between 'a' and 'b'.

This is interesting as it is much closer to my real problem. Extension
'a' provides some converters from numpy objects to my own C++ types and
back. And these guys I would like to use in 'b' (along with some other
numpy utility functions). 

regards
  Eugen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20141023/a55d4967/attachment-0001.sig>

From stefan at seefeld.name  Fri Oct 24 13:09:42 2014
From: stefan at seefeld.name (Stefan Seefeld)
Date: Fri, 24 Oct 2014 07:09:42 -0400
Subject: [C++-sig] Exposing simple polymorphism with boost python
In-Reply-To: <CAEWxakKUy6iCQ1ZfxLpoi=VFzSRyTbaBMyjpMvCjiJqgKAHsCg@mail.gmail.com>
References: <CAEWxakKUy6iCQ1ZfxLpoi=VFzSRyTbaBMyjpMvCjiJqgKAHsCg@mail.gmail.com>
Message-ID: <544A3376.8020309@seefeld.name>

On 23/10/14 03:38 AM, Erik T?rke wrote:
> Hi Python-Experts :-)
>
>
> i am starting to get really frustrated trying to expose a simple C++
> polymorphism to python with boost::python.
> I do have the following structure in C++:
>
>     struct Base {
>         int typeID;
>     };
>
>     struct Derived : public Base {
>         int derivedProperty;
>     }
>
>     //and some more from base derived types....    
>
>     Base *returnSomethingDerivedFromBase(...) {
>         Derived *ret = new Derived;
>         ret->derivedProperty = 1234;
>         return ret;
>     }
>
>     BOOST_PYTHON_MODULE(foo)
>     {
>         class_<Base>("Base")
>             .add_property("baseProperty", &Base::baseProperty);
>
>         class_<Derived, bases<Base> >("Derived")
>             .add_property("derivedProperty", &Derived::derivedProperty);
>
>         def("returnSomethingDerivedFromBase",
> returnSomethingDerivedFromBase);    
>     }
>
>
> And in Python i just want to have the following:
>
>     object = returnSomethingFromDerived() #object is of type Base
>     if object.typeID = 1:

Typo: you likely mean '==', not '='.

>         #here i want to cast to Derived and access "derivedProperty"
>         #but this is not working :-( :
>         object.__class__ = Derived

That's indeed  not possible. But I also don't know why you want that.
The objet presumably already is of type 'Derived', so there is nothing
to cast. (In Python all attribute lookups happen at call-time.)

>
> Is there a way to accomplish this at all? Or isn?t this possible as it
> would be in C++ ?

Both C++ and Python are strongly typed (i.e., all objects have a
specific type, with specific methods bound to them). But contrary to
C++, Python also is dynamically typed, so you can reassign a new object
with a different type to an existing variable. In that context, casting
isn't of any use.

Or perhaps a more complete example would be useful to demonstrate your
needs, so we can look into how best to support that in Python.
HTH,
        Stefan

-- 

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


From stefan at seefeld.name  Fri Oct 24 13:12:39 2014
From: stefan at seefeld.name (Stefan Seefeld)
Date: Fri, 24 Oct 2014 07:12:39 -0400
Subject: [C++-sig] sharing code between different python extensions
In-Reply-To: <35E004AD6290A7438FCA34BBF325F41606996A7B@ADXV2.win.desy.de>
References: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>
 <54490793.9030009@seefeld.name>
 <35E004AD6290A7438FCA34BBF325F41606996A7B@ADXV2.win.desy.de>
Message-ID: <544A3427.80206@seefeld.name>

On 23/10/14 10:33 AM, Wintersberger, Eugen wrote:
> Hi Stefan
>   
>> Python extension modules may not depend on each other in that way.
>> (Arguably that is a Good Thing, as it avoids possible ABI compatibility
>> issues.)
>> What I suggest you do is either refactor the code such that your
>> extensions 'a' and 'b' both link to a shared library 'c' which provides
>> the symbols used by both. 
> If the real problem would be as in the example I would definitely go
> with this approach (I even tried to do so). However, the real problem is
> more complex. The functions in 'a' call Python API and numpy API
> functions. Thus, when distutils builds the code it does this according
> to a particular Python version. So building a single shared library
> would not help too much. 
>
>> Alternatively you could try to reduce the
>> dependency to only exist at the Python interface level, such that using
>> 'b' requires 'a' being loaded (for example to enable type converters
>> defined in 'a' but used in 'b'), but without any direct ABI dependencies
>> between 'a' and 'b'.
> This is interesting as it is much closer to my real problem. Extension
> 'a' provides some converters from numpy objects to my own C++ types and
> back. And these guys I would like to use in 'b' (along with some other
> numpy utility functions).

And why is that approach then not working for you ?

    Stefan

-- 

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


From eugen.wintersberger at desy.de  Tue Oct 28 11:46:47 2014
From: eugen.wintersberger at desy.de (Wintersberger, Eugen)
Date: Tue, 28 Oct 2014 11:46:47 +0100
Subject: [C++-sig] sharing code between different python extensions
In-Reply-To: <544A3427.80206@seefeld.name>
References: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>
 <54490793.9030009@seefeld.name>
 <35E004AD6290A7438FCA34BBF325F41606996A7B@ADXV2.win.desy.de>
 <544A3427.80206@seefeld.name>
Message-ID: <35E004AD6290A7438FCA34BBF325F41606996A7F@ADXV2.win.desy.de>

Hi Stefan

On Fri, 2014-10-24 at 07:12 -0400, Stefan Seefeld wrote:
> ....
> >
> >> Alternatively you could try to reduce the
> >> dependency to only exist at the Python interface level, such that using
> >> 'b' requires 'a' being loaded (for example to enable type converters
> >> defined in 'a' but used in 'b'), but without any direct ABI dependencies
> >> between 'a' and 'b'.
> > This is interesting as it is much closer to my real problem. Extension
> > 'a' provides some converters from numpy objects to my own C++ types and
> > back. And these guys I would like to use in 'b' (along with some other
> > numpy utility functions).
> 
> And why is that approach then not working for you ?
> 
>     Stefan
> 

Well, I think I found a solution. However, I have no idea how to do this
with distutils. As you suggested I will build a shared library with the
common code but bound to a particular Python version. It should be
installed in 

$PREFIX/lib/pythonX.Y/some more directories

and header files to 

$PREFIX/include/pythonX.Y/some more directories

What I still do not know is how to build the extension module along with
the shared library with distutils ;). I guess I will put this question
on the Python list - or maybe someone at this list has an idea how to do
this. 
Thanks for all your efforts so far. 

regards
  Eugen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20141028/ba9f70fc/attachment.sig>

From stefan at seefeld.name  Tue Oct 28 15:53:11 2014
From: stefan at seefeld.name (Stefan Seefeld)
Date: Tue, 28 Oct 2014 10:53:11 -0400
Subject: [C++-sig] sharing code between different python extensions
In-Reply-To: <35E004AD6290A7438FCA34BBF325F41606996A7F@ADXV2.win.desy.de>
References: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>
 <54490793.9030009@seefeld.name>
 <35E004AD6290A7438FCA34BBF325F41606996A7B@ADXV2.win.desy.de>
 <544A3427.80206@seefeld.name>
 <35E004AD6290A7438FCA34BBF325F41606996A7F@ADXV2.win.desy.de>
Message-ID: <544FADD7.1000503@seefeld.name>

On 28/10/14 06:46 AM, Wintersberger, Eugen wrote:
> Hi Stefan
>
> On Fri, 2014-10-24 at 07:12 -0400, Stefan Seefeld wrote:
>> ....
>>>> Alternatively you could try to reduce the
>>>> dependency to only exist at the Python interface level, such that using
>>>> 'b' requires 'a' being loaded (for example to enable type converters
>>>> defined in 'a' but used in 'b'), but without any direct ABI dependencies
>>>> between 'a' and 'b'.
>>> This is interesting as it is much closer to my real problem. Extension
>>> 'a' provides some converters from numpy objects to my own C++ types and
>>> back. And these guys I would like to use in 'b' (along with some other
>>> numpy utility functions).
>> And why is that approach then not working for you ?
>>
>>     Stefan
>>
> Well, I think I found a solution. However, I have no idea how to do this
> with distutils. As you suggested I will build a shared library with the
> common code but bound to a particular Python version. It should be
> installed in 
>
> $PREFIX/lib/pythonX.Y/some more directories
>
> and header files to 
>
> $PREFIX/include/pythonX.Y/some more directories
>
> What I still do not know is how to build the extension module along with
> the shared library with distutils ;). I guess I will put this question
> on the Python list - or maybe someone at this list has an idea how to do
> this. 
> Thanks for all your efforts so far. 

Eugen,

For avoidance of doubt, I don't think I'm able to help you with that. I
have used distutils in the past, but found it pretty limited in its
support of extension modules.
I ended up adding a few custom commands to build pure C++ libraries
(specifically for dependencies shared by multiple extension modules).
That was never particularly elegant or generic, and so I don't think
it's worth reusing this.

An example of this you can find in
https://github.com/stefanseefeld/synopsis/tree/master/Synopsis/dist (in
case you are brave enough :-) ). I haven't touched that code in quite a
while, and there may be much better solutions these days using more
modern substitutes for the distutils package.

Regards,
        Stefan


-- 

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


From eugen.wintersberger at desy.de  Tue Oct 28 16:21:59 2014
From: eugen.wintersberger at desy.de (Wintersberger, Eugen)
Date: Tue, 28 Oct 2014 16:21:59 +0100
Subject: [C++-sig] sharing code between different python extensions
In-Reply-To: <544FADD7.1000503@seefeld.name>
References: <35E004AD6290A7438FCA34BBF325F41606996A76@ADXV2.win.desy.de>
 <54490793.9030009@seefeld.name>
 <35E004AD6290A7438FCA34BBF325F41606996A7B@ADXV2.win.desy.de>
 <544A3427.80206@seefeld.name>
 <35E004AD6290A7438FCA34BBF325F41606996A7F@ADXV2.win.desy.de>
 <544FADD7.1000503@seefeld.name>
Message-ID: <35E004AD6290A7438FCA34BBF325F41606996A85@ADXV2.win.desy.de>

Hi Stefan
On Tue, 2014-10-28 at 10:53 -0400, Stefan Seefeld wrote:
> For avoidance of doubt, I don't think I'm able to help you with that. I
> have used distutils in the past, but found it pretty limited in its
> support of extension modules.
> I ended up adding a few custom commands to build pure C++ libraries
> (specifically for dependencies shared by multiple extension modules).
> That was never particularly elegant or generic, and so I don't think
> it's worth reusing this.
> 
> An example of this you can find in
> https://github.com/stefanseefeld/synopsis/tree/master/Synopsis/dist (in
> case you are brave enough :-) ). I haven't touched that code in quite a
> while, and there may be much better solutions these days using more
> modern substitutes for the distutils package.
> 
> Regards,
>         Stefan
> 
> 
Anyhow - thanks for the link. I will have a look on this. Currently I am
waiting for response from the Python list. Let's see if those guys have
a clever idea. 

regards
  Eugen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20141028/6648282d/attachment.sig>

From josh.davidson at lmco.com  Wed Oct 29 16:34:28 2014
From: josh.davidson at lmco.com (Davidson, Josh)
Date: Wed, 29 Oct 2014 15:34:28 +0000
Subject: [C++-sig] Boost.Python and thread safety
Message-ID: <86299D4CFE2C1248AA41ACF782B0D1431DB7B5DC@HDXDSP33.us.lmco.com>

Hi all, I'm trying to determine if the following constitutes a thread safety violation with Python.

To simplify the discussion, let's say have the following fictional classes:
* Teacher - Fully implemented in Python
* Student - Implemented in C++ with Boost.Python bindings
* Quiz - Implemented in C++ with Boost.Python bindings


In a Python interpreter, a single instance of a teacher is instantiated and multiple instances of students are instantiated (via the bindings).  The teacher then instantiates a number of quiz objects (via the bindings) and invokes a method on the student class that takes a reference to a quiz object.  The teacher objects kicks off a Python thread that blocks until all students are completed with the quiz.  The student objects set attributes on their assigned quiz objects until they are done.  

However, if during the course of taking the test, a student kicks of a C++ (Boost) thread, say to scan his classmates' papers, and in that non-Python thread without the GIL, invokes getters/setters on the quiz object, is that a violation of thread safety?   The quiz object is protected from concurrent access.  If the quiz object was instantiated from a C++ application and passed in there would definitely be no problem.  If the quiz object is instantiated via the bindings and passed into the C++ student, I'm not so sure since there would be a thread accessing a (wrapped) Python object from threads that don't hold the GIL.

Thanks,
Josh