Re: [C++-sig] strange behavior with respect to numeric and Boolean overloads
On Monday 16 March 2009 22:52:16 Ralf W. Grosse-Kunstleve wrote: > [...] Boost.Python 2 was written when the Python bool type still really > was an int (Python 2.2). [...] On Tuesday 17 March 2009 06:40:14 Roman Yakovenko wrote: > Python code: > > def foo( arg ): > if isinstance( arg, int ): > _foo_int( arg ) > else: > _foo_bool( arg ) Now I am confused. Both of the above read as if a boolean was no longer an int, but I interpret "is a" and "isinstance" as checking for types inherited from, too?! While Ralf could have meant (True is 1) with his "really", the above code should first test whether isinstance( arg, bool ), no? Or did this change with 2.6/3? Greetings, Hans ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] strange behavior with respect to numeric and Booleanoverloads
isinstance( True, int ) returns True However, the code def foo( arg ): if isinstance( arg, bool ): _foo_bool( arg ) else: _foo_other( arg ) Would work in theory. I could do this. I'm just annoyed that BP is not doing it for me. -Original Message- From: cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@python.org [mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@py thon.org] On Behalf Of Hans Meine Sent: Tuesday, March 17, 2009 5:03 AM To: Development of Python/C++ integration Subject: Re: [C++-sig] strange behavior with respect to numeric and Booleanoverloads On Monday 16 March 2009 22:52:16 Ralf W. Grosse-Kunstleve wrote: > [...] Boost.Python 2 was written when the Python bool type still really > was an int (Python 2.2). [...] On Tuesday 17 March 2009 06:40:14 Roman Yakovenko wrote: > Python code: > > def foo( arg ): > if isinstance( arg, int ): > _foo_int( arg ) > else: > _foo_bool( arg ) Now I am confused. Both of the above read as if a boolean was no longer an int, but I interpret "is a" and "isinstance" as checking for types inherited from, too?! While Ralf could have meant (True is 1) with his "really", the above code should first test whether isinstance( arg, bool ), no? Or did this change with 2.6/3? Greetings, Hans ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] strange behavior with respect to numeric and Booleanoverloads
I have a quasi-fix for this to the library itself, (see diff below)
buuut it breaks a certain case: if you have a wrapped c++ function that
takes a bool, and you try to pass it an int, you get a
ArgumentError: Python argument types in
builtin_converters_ext.rewrap_const_reference_bool(int)
did not match C++ signature:
rewrap_const_reference_bool(bool)
so you have to call the function with an explicit cast to bool:
c++:
void takes_a_bool(bool b) { ... };
def("py_takesbool", takes_a_bool);
py:
py_takesbool(bool(33))
to get things to work. This breaks a lot of tests, I'm digging further.
Index: converter/builtin_converters.cpp
===
--- converter/builtin_converters.cpp(revision 51812)
+++ converter/builtin_converters.cpp(working copy)
@@ -99,8 +99,13 @@
if (number_methods == 0)
return 0;
- return (PyInt_Check(obj) || PyLong_Check(obj))
- ? &number_methods->nb_int : 0;
+ return (
+#if PY_VERSION_HEX >= 0x0204
+ !PyBool_Check(obj) &&
+#endif
+ (PyInt_Check(obj) || PyLong_Check(obj)))
+
+ ? &number_methods->nb_int : 0;
}
static PyTypeObject const* get_pytype() { return &PyInt_Type;}
};
@@ -135,7 +140,11 @@
if (number_methods == 0)
return 0;
- return (PyInt_Check(obj) || PyLong_Check(obj))
+ return (
+#if PY_VERSION_HEX >= 0x0204
+ !PyBool_Check(obj) &&
+#endif
+ (PyInt_Check(obj) || PyLong_Check(obj)))
? &py_object_identity : 0;
}
static PyTypeObject const* get_pytype() { return &PyInt_Type;}
@@ -226,7 +235,11 @@
{
static unaryfunc* get_slot(PyObject* obj)
{
+#if PY_VERSION_HEX >= 0x0204
+ return obj == Py_None || PyBool_Check(obj) ? &py_object_identity : 0;
+#else
return obj == Py_None || PyInt_Check(obj) ?
&py_object_identity : 0;
+#endif
}
static bool extract(PyObject* intermediate)
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Some thoughts on py3k support
Hi, Here is some thoughts on GSoC Boost.Python py3k support project. First thing come into my mind is the build system. For Python 3, we would have a separate build target, eg. having libboost_python.so built for Python 2.x and libboost_python3.so for Python 3. This would match the current situation that most Linux distro packaged Python 3 in a way that lives together with Python 2.x. There's two build system for Boost now - cmake and bjam. Personally I want to start with cmake, and finally both of the two will up to date for Python 3. I have read some piece of Boost.Python code in these, it is understandable for me. And I'd say the usage of template metaprogramming is really smart! Thanks to the high level abstraction, there would be just a little code interfaced to Python C-API directly. So there would not be so much works. However there are something we need to take care of. One of them is, in Python 3, string is unicode (and the old string class is called bytes in Python 3). So if we have a C function char const* hello(); // returns a "Hello" According to the current behavior of Boost.Python converters, the wrapped function in Python 3 will return a b"Hello" (which is a bytes object but not a string). So code like this will broken: if "Hello" == hello(): ... Because string object "Hello" is not equal to bytes object b"Hello" returned by hello(). We may change the behavior of converter to return a unicode string in Python 3, that would keep most of existing code compatible. Anyway there will be code really need a single byte string returned, a new converter can be explicitly specified for this. There are more issues similar to this. I'll figure out more and write a detailed proposal as soon as possible. Best regards, Haoyu Bai ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
On Sat, Mar 14, 2009 at 9:29 PM, Stefan Seefeld wrote: > David Abrahams wrote: >> >> On Mar 14, 2009, at 4:28 AM, Niall Douglas wrote: >> >>> >>> Would it make sense if Dave acted as second as in "person we fall >>> back upon if the primaries can't figure it out?" >> >> That would make plenty of sense to me. I'd be very happy to have others >> leading the mentoring effort. But we may have missed the GSoC application >> deadline by now. I'm not sure whether anyone signed us up. > > I believe we are on track. And I agree, too: It might be wise if people like > Niall and myself did the official mentoring, while being able to relay > questions we can't answer on our own to David. > > This could become a productive summer for boost.python ! > > Thanks, > Stefan > Hi, I'm very happy to see so much interest in this project. You are all experts on Boost.Python so I'd glad to see anyone of you to mentor this. I'm looking forward for this summer! I'll post more questions and proposals etc. to Python c++-sig mailling list, since that is focused on Boost.Python. Thanks! -- Haoyu Bai ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Some thoughts on py3k support
A thought on this bytes vs. strings: I am not sure if others do the same thing, but: There are a number of places where the underlying library that we are wrapping has a char* or a char[] that can be either a null terminated string or an arbitrary bag of bytes depending on context. The fact that python uses strings for arbitrary bags of bytes has been convenient for us in this regard. I can work with whatever you come up with, but it might convenient if a char* or char[] was treated as a bytes object and a std::string was treated as a string. Thoughts? -Original Message- From: cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@python.org [mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@py thon.org] On Behalf Of Haoyu Bai Sent: Tuesday, March 17, 2009 1:08 PM To: Development of Python/C++ integration Subject: [C++-sig] Some thoughts on py3k support However there are something we need to take care of. One of them is, in Python 3, string is unicode (and the old string class is called bytes in Python 3). So if we have a C function char const* hello(); // returns a "Hello" According to the current behavior of Boost.Python converters, the wrapped function in Python 3 will return a b"Hello" (which is a bytes object but not a string). So code like this will broken: if "Hello" == hello(): ... Because string object "Hello" is not equal to bytes object b"Hello" returned by hello(). We may change the behavior of converter to return a unicode string in Python 3, that would keep most of existing code compatible. Anyway there will be code really need a single byte string returned, a new converter can be explicitly specified for this. There are more issues similar to this. I'll figure out more and write a detailed proposal as soon as possible. Best regards, Haoyu Bai ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Smart pointer, polymorphism issue
Hello,
I have created a Python wrapper using a custom smart pointer that
is defined
in the following manner:
class_>("Event", init<>())
.def("f", &Event::f, &EventWrapper::default_f).
implicitely_convertible, Ptr>();
register_ptr_to_python>();
Now... when I subclass
this in Python like so:
class MyEvent(Event):
def f(self):
return 42
I can use MyEvent as expected only within Python code... when I
pass an
instance of MyEvent to C++, and then C++ passes MyEvent back
to
Python, I no longer am able to call the overridden method f in
Python.
Calling f in Python invokes Event::f, as opposed to
MyEvent.f
This only happens when I construct MyEvent in Python code, pass
the instance
to some C++ code, and have the C++ code pass back the
MyEvent instance
back to Python.
Any ideas why this may
be?
Thanks.
_
Share photos with friends on Windows Live Messenger
http://go.microsoft.com/?linkid=9650734___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Some thoughts on py3k support
Matthew Scouten (TT) wrote: I can work with whatever you come up with, but it might convenient if a char* or char[] was treated as a bytes object and a std::string was treated as a string. Thoughts? A char* can never be fully treated as a bytes object. You must mean a char* plus a size_t (or two char* iterator pointers). At which point any convenience you think you are getting from treating char* as bytes is gone as you have to introduce an intermediate type anyway to put in the "buffer" semantics. Hence you are better off with real buffer objects, or equivalents thereof. Say a std::pair iterator range, or std::vector, etc. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
