Prev: do
Next: zipimport (.pyd & .so) files.
From: Alf P. Steinbach /Usenet on 13 Jul 2010 17:22
* sturlamolden, on 13.07.2010 22:06:
> On 13 Jul, 21:39, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...(a)gmail.com> wrote:
>
>> Thanks! It seems that SCXX does those things that I've been planning to do but
>> haven't got around to (wrapping standard Python types), while what it doesn't do
>> (abstracting away all those tables etc. and mapping Python calls to C++ calls)
>> is what I've been working on. Which could be a Very Nice combination except that
>> I'm assuming Py3, while SCXX seems to be Py2 only. :-(
>
> I'd suggest PyCXX instead. http://cxx.sourceforge.net
>
> SCXX is a tiny wrapper mostly used in scipy.weave to inline C++ in
> Python.

Thanks. I looked up your URL, and PyCXX design goals seem to be much like what
I'm doing, but different in some crucial ways. It's probably great, but it's not
to my taste.

E.g. the PyCXX String class interface:


explicit String( PyObject *pyob, bool owned = false )
String( const Object &ob )
String()
String( const char *latin1 )
String( const char *latin1, Py_ssize_t size )
String( const std::string &latin1 )
String( const std::string &v, const char *encoding, const char *error=NULL )
String( const char *s, const char *encoding, const char *error=NULL )
String( const char *s, Py_ssize_t len, const char *encoding, const char
*error=NULL )
String & operator=( const Object &o )
String & operator=( PyObject *p )
String & operator=( const unicodestring &v )
size_type size() const
size_type capacity() const
unicodestring as_unicodestring() const
std::string operator std::string() const
String encode( const char *encoding, const char *error="strict" )
std::string as_std_string( const char *encoding=NULL, const char
*error="strict" ) const


In C++ the only way to portably specify a string literal with national
characters, is as a wide string literal. Otherwise the result depends on the
source code encoding. Yet PyCXX's String does not support wchar_t.

Also, things like the 'owned' option is just asking for trouble.

I chose this example because a Python string wrapper is the only object wrapper
(apart from a general PyPtr) that I've implemented so far. The PyCXX string
wrapper fails the design criterions of general usability (including in
particular lack of wide char support) and safety (in particular the 'owned'
option). And it's underdocumented, like, what encoding does the operator
std::string() produce?

The details don't matter though. I'm sure that PyCXX is Very Nice for its
purpose, as is e.g. Boost.Python (which is Very Very Nice for its purpose). :-)


Cheers, & thanks for the link,

- Alf

--
blog at <url: http://alfps.wordpress.com>
From: sturlamolden on 13 Jul 2010 17:28
On 13 Jul, 22:35, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...(a)gmail.com> wrote:

> Yes, I know Boost.Python in more detail and I've heard of all the rest except
> SIP,


In my opinion, SIP is the easiest way of integrating C++ and Python.
Just ignore the PyQt stuff.

http://www.riverbankcomputing.co.uk/static/Docs/sip4/using.html#a-simple-c-example
http://www.riverbankcomputing.co.uk/software/sip/intro

(SIP 4 can also expose C libraries to Python, not just C++.)


From: Hrvoje Niksic on 14 Jul 2010 04:17
"Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet(a)gmail.com> writes:

> Also, things like the 'owned' option is just asking for trouble.

Isn't owned=true (or equivalent) a necessity when initializing from a
PyObject* returned by a function declared to return a "new reference"?

How does your API deal with the distinction between new and borrowed
references?
First  |  Prev  | 
Pages: 1 2 3
Prev: do
Next: zipimport (.pyd & .so) files.