C++ version of the C Python API?

[Robert Dailey]

Hi,

Is there a C++ version of the C Python API packaged with python 2.5?
It would be nice to have a OOP approach to embedding python in C++. It
would also be a bonus if this C++ Python API cleaned up a lot of the
messy code involved in embedding python.

Thanks.

 

[Stargaming]

Hi,

Is there a C++ version of the C Python API packaged with python 2.5? It
would be nice to have a OOP approach to embedding python in C++. It
would also be a bonus if this C++ Python API cleaned up a lot of the
messy code involved in embedding python.

Thanks.

Perhaps, the remark about `C++ extensions`_ or `Embedding in C++`_ in the
`Extending and Embedding`_ docs (described on doc.python.org as a
"tutorial for C/C++ programmers") can help.

Depending on your level of embedding, those random annotations spread
over the extending docs, found with a little patience and ctrl+f, might
help:

* "In C++, the operators new and delete are used with essentially the
same meaning and we'll restrict the following discussion to the C case."
-- `1.10 Reference counts <http://docs.python.org/ext/refcounts.html>`_
* "Note that PyMODINIT_FUNC declares the function as void return type,
declares any special linkage declarations required by the platform, and
for C++ declares the function as extern "C"." -- `1.4 The Module's Method
Table and Initialization Function <http://docs.python.org/ext/
methodTable.html>`_

Cheers,
Stargaming

... _C++ extensions: http://docs.python.org/ext/cplusplus.html
... _Embedding in C++: http://docs.python.org/ext/embeddingInCplusplus.html
... _Extending and embedding: http://docs.python.org/ext/ext.html

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Is there a C++ version of the C Python API packaged with python 2.5?

Stargaming has already mentioned the fine points; the first answer is:
yes, the API packaged python 2.5 can be used with C++. It is a C++
version of the same API as it adds proper extern "C" declarations around
all prototypes, and it was specifically cleaned up (ten years ago)
to work with C++.

This API does not make use of many of the C++ features, including
classes, templates, or overloading.

Regards,
Martin

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Is there a C++ version of the C Python API packaged with python 2.5?

Stargaming has already mentioned the fine points; the first answer is:
yes, the API packaged python 2.5 can be used with C++. It is a C++
version of the same API as it adds proper extern "C" declarations around
all prototypes, and it was specifically cleaned up (ten years ago)
to work with C++.

This API does not make use of many of the C++ features, including
classes, templates, or overloading.

Regards,
Martin

 

[Robert Dailey]

Stargaming has already mentioned the fine points; the first answer is:
yes, the API packaged python 2.5 can be used with C++. It is a C++
version of the same API as it adds proper extern "C" declarations around
all prototypes, and it was specifically cleaned up (ten years ago)
to work with C++.

This API does not make use of many of the C++ features, including
classes, templates, or overloading.

Regards,
Martin

Well C++ implicitly includes OOP since that is the foundation of the
language. I was more or less asking if there was an object oriented
version of the Python embedded API or perhaps an OO wrapper. However
it doesn't seem that way, so I may have to make my own.

Thanks for the responses.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Well C++ implicitly includes OOP since that is the foundation of the

language. I was more or less asking if there was an object oriented
version of the Python embedded API or perhaps an OO wrapper. However
it doesn't seem that way, so I may have to make my own.

I think you are misinterpreting what you are seeing. The Python C API
*is* object-oriented. It has all features of object-orientation:
classes, encapsulation, polymorphism, late binding, ...

As for "make your own": people have tried this before; there are
multiple C++ wrappers around the Python C API available.

Regards,
Martin

 

[Robert Dailey]

I think you are misinterpreting what you are seeing. The Python C API
*is* object-oriented. It has all features of object-orientation:
classes, encapsulation, polymorphism, late binding, ...

As for "make your own": people have tried this before; there are
multiple C++ wrappers around the Python C API available.

Regards,
Martin

Could you emphasize a little more? I haven't worked much at all with
the Python C API, so I may be misunderstanding. First of all, you say
that the "Python C API is object oriented", which is contradictory
because it should read "Python C++ API is object oriented". Perhaps
this is a typo, or maybe you're referencing some C++ wrapper for the
Python C API that you failed to mention the name of.

You also mentioned that there are "multiple C++ wrappers arround the
Python C API Available"... could you provide names for a few of the
popular ones?

Thanks again!

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Could you emphasize a little more? I haven't worked much at all with

the Python C API, so I may be misunderstanding. First of all, you say
that the "Python C API is object oriented", which is contradictory
because it should read "Python C++ API is object oriented". Perhaps
this is a typo, or maybe you're referencing some C++ wrapper for the
Python C API that you failed to mention the name of.

No, I literally meant that the Python C API is object-oriented.
You don't need an object-oriented language to write object-oriented
code.

You also mentioned that there are "multiple C++ wrappers arround the
Python C API Available"... could you provide names for a few of the
popular ones?

The most popular ones are Boost.Python, CXX, and PySTL.

Regards,
Martin

 

[Robert Dailey]

No, I literally meant that the Python C API is object-oriented.
You don't need an object-oriented language to write object-oriented
code.

I disagree with this statement. C is not an object oriented language,
and I've seen attempts to make it somewhat object oriented, however it
failed miserably in readability and manageability overhead. However,
this isn't the place to discuss such a thing so I've got nothing more
to say than that.

I do appreciate you taking the time to respond to my inquiry and offer
a few C++ wrapper API's for the Python C API. Take care!

 

[Alex Martelli]

The most popular ones are Boost.Python, CXX, and PySTL.

I think SIP is also pretty popular (see
<http://www.riverbankcomputing.co.uk/sip/>).


Alex

 

[Carl Banks]

I disagree with this statement. C is not an object oriented language,
and I've seen attempts to make it somewhat object oriented, however it
failed miserably in readability and manageability overhead. However,
this isn't the place to discuss such a thing so I've got nothing more to
say than that.

What he means is that the C API provides a complete, if boilerplate-
heavy, interface to object oriented aspects of Python. I.e., you can
write Python types completely in C, including all the OOPy stuff like
inheritance and so on. You don't need a language with built-in support
of OOP to do that.

Now, a C++ API for CPython would necessarily be built on top of the C
API, which carries some limitations relative to the OOP abilities of C++
itself. I suspect all you'll get from a C++ binding is a slightly more
comfortable (to people who like C++) calling interface. It could help
bring some unity to your extension code, and maybe get rid of a few
typecasts and simplify function names. But you shouldn't expect anything
like the ability to freely inherit between C++ and Python classes.


Carl Banks

 

[Michael L Torrie]

I disagree with this statement. C is not an object oriented language,
and I've seen attempts to make it somewhat object oriented, however it
failed miserably in readability and manageability overhead. However,
this isn't the place to discuss such a thing so I've got nothing more
to say than that.

Guess you haven't programmed in GTK+ on C, then. Very heavy in
object-oriented programmin. C++'s OOP stuff is just pure syntactic
sugar, nothing more, nothing less.

Python's OO nature is a bit deeper, since we're talking a dynamic
language. Scheme, another dynamic language, is not inherently OO or
non-OO. You can use it in either fashion.

I do appreciate you taking the time to respond to my inquiry and offer
a few C++ wrapper API's for the Python C API. Take care!

Any C++ version of the python API is by definition going to be a wrapper
around the C version. Even the C version is a wrapper around the python
object model.

 

[Aahz]

Is there a C++ version of the C Python API packaged with python 2.5?
It would be nice to have a OOP approach to embedding python in C++. It
would also be a bonus if this C++ Python API cleaned up a lot of the
messy code involved in embedding python.

One other thing: you may get more advice from C++-sig and/or capi-sig;
mail.python.org has the info for subscribing to those.

 

[Nicholas Bastin]

Now, a C++ API for CPython would necessarily be built on top of the C
API, which carries some limitations relative to the OOP abilities of C++
itself.

It wouldn't have to be, although it'd be much more of a maintenance
nightmare if it poked into the Python internals.

But you shouldn't expect anything like the ability to freely inherit between
C++ and Python classes.

You can do this with Boost.Python.

 

[Nicholas Bastin]

I disagree with this statement. C is not an object oriented language,
and I've seen attempts to make it somewhat object oriented, however it
failed miserably in readability and manageability overhead. However,
this isn't the place to discuss such a thing so I've got nothing more
to say than that.

Object-oriented programming is a design choice, not a language
feature. You can write straight procedural code in C++, and you can
write object oriented code in C. Sure, C++ has some language features
which facilitate object-oriented programming, but it doesn't magically
make your code object-oriented. You can certainly write basic
object-oriented code in C and hide most of the implementation in
preprocessor macros if you so desire.

 

[Robert Dailey]

Object-oriented programming is a design choice, not a language
feature. You can write straight procedural code in C++, and you can
write object oriented code in C. Sure, C++ has some language features
which facilitate object-oriented programming, but it doesn't magically
make your code object-oriented. You can certainly write basic
object-oriented code in C and hide most of the implementation in
preprocessor macros if you so desire.

Well, perhaps what I meant was I personally would not turn to C for
OOP. As I said before, I've seen OOP attemps using C and it was VERY
unattractive (this coming from a C++ programmer of course). It just
doesn't make sense to me why you'd choose an OOP approach in a
language that makes it messy over a language that had OOP in mind when
it was designed. There are far better languages (which, as you said,
have features to facilitate OOP) that I would choose long before I
chose C, such as C++.

Yes, I agree you can do OOP in any language as it is just a concept,
however there are other entities that can greatly affect which
language you choose to intake such a responsibility. For example, I'd
choose Python OOP over C++ OOP because to me Python code is cleaner
and has less syntax redundancy. You get to read the important stuff
more quickly. A lot of people would disagree in that whitespace does
not make code more readable than operator delimiters, however this is
just my opinion. In addition, I'd choose Python OOP over C++ OOP for
quick applications that didn't require a great amount of performance
(such as a level editor for a game). For the game itself, I'd choose
C++ OOP because it is way more flexible and allows me to optimize the
game for speed as best as I can, whereas with python you can only
optimize only to a certain point (as with any language), which still
may not be fast enough. In any case, it's really not fair to compare
speed between an interpreted language vs a compiled language.

Given what I've learned and things I've come to like, I doubt I'd do
any sort of programming ever again that didn't involve some sort of
object oriented design. That's just my preference. This preference, in
turn, is what motivated my original question. The CPython API
interface itself seems modularized, NOT object oriented (only from
what I saw). Boost.Python, as so many have already noted, is a wrapper
over that interface introducing C++ which provides the OOP I am
looking for.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

This preference, in

turn, is what motivated my original question. The CPython API
interface itself seems modularized, NOT object oriented (only from
what I saw).

I suggest you look again, then. Things like PyObject_String,
PyObject_GetAttrString, or PySequence_GetItem all express the
object-orientation in the API. The hide the actual implementation
of how string conversion is done, how attribute names are converted
to attribute values, and how an item in an enumerable sequence is
accessed. They exhibit polymorphism, late binding, and encapsulation,
which are among the core properties of object-orientation. The
C API (although not these three functions) also supports inheritance,
which is the core property missing in the previous list.

Regards,
Martin