Mailman 3 March 2009 - capi-sig

ANNOUNCE: PyBindGen 0.8
by Gustavo Carneiro 10 Mar '22

10 Mar '22

The other day I released PyBindGen 0.8. Main news is that it features a new experimental header file scanner based on pygccxml (i.e., it's similar to py++ in scope, if not in maturity, but does not use boost.pythonunderneath). == What == PyBindGen is a Python module that is geared to generating C/C++ code that binds a C/C++ library for Python. It does so without extensive use of either C++ templates or C pre-processor macros. It has modular handling of C/C++ types, and can be easily extended with Python plugins. The generated code is almost as clean as what a human programmer would write, and does not depend on any library or header files besides Python itself. == Where == https://launchpad.net/pybindgen/ == NEWS == - Support C++ instance attributes through getter/setter methods - Support functions as methods of C++ classes - Support the PyObject* type - Support unsigned int, C strings (char*) (from Mark Lee) - Add basic support for enum types - New experimental automatic module generator based on C/C++ header file scanner and annotations in comments, using pygccxml - Some bug fixes -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert

2 1

Garbage output from warnings with embedded python
by Campbell Barton 29 May '09

29 May '09

Recently I wanted to deprecate some functions in our the C api, and found that warnings give weired output when running through through our C api. A simple test is to do this... print range(1.5) When I run this from python I get good output.. test.py:1: DeprecationWarning: integer argument expected, got float print range(1.5) But when running from our C api I get /home/ideasman42/blender-svn/blender/blender.bin:1: DeprecationWarning: integer argument expected, got float ELF�p40�"4()&44�4�44�4��F��F��F�K �K ğ<@G�K �K xxHH�H� P�td�2?��C ��C L,L,Q�td/lib/ld-linux.so.2GNU��8�1LQ �U�N�.yH {��d I thought this was todo with running a compiled string so I tried PyRun_String() on the text buffer instead of PyEval_EvalCode() but the same problem. Id be interested to know if anyones embedded python gives proper warnings. On Linux testing with python 2.6 here. -- - Campbell

2 3

CPython and C++ object GC
by Csaba Balazs 30 Mar '09

30 Mar '09

Hello Everybody, I would like to use a C++ gui library with the following (simplified) interface in Python. #include <stdio.h> class Gui; class GuiObject { public: GuiObject(Gui *Gui) {printf("creating GuiObject(gui: %X)\n", Gui);} ~GuiObject() {printf("deleting GuiObject\n");} void Move(int x, int y) {printf("GuiObject move(%d, %d)\n", x, y);}; }; class Gui { public: Gui() {printf("creating Gui\n");} ~Gui() {printf("deleting Gui\n");} GuiObject* AddImage() { GuiObject* ob = new GuiObject(this); return ob; } void Print() {printf("Gui: %X\n", this);} }; int main() { Gui *gui = new Gui(); gui->Print(); GuiObject *obj = gui->AddImage(); obj->Move(50, 50); /*GuiObject *obj2 = new GuiObject(gui); // not allowed delete obj2;*/ delete obj; delete gui; return 0; } I created the Python Gui and GuiObject classes (PyTypeObject), and added it to main module (PyModule_AddObject). It works, but there is a problem at the Gui::AddImage(), with constructs a new GuiObject, which is available in Python layer but finally it is not collected and freed by GC: ... obj = _PyObject_New(&GuiObjectType); PyObject_Init(obj, &GuiObjectType); ... I cannot invoke the GuiObject object constructor directly from Python, because of the implementation of the C++ gui library (in this case it would be collected). I use the embedded CPython as an interpreter, so I cannot add additional external .py file for it. So the following Python code would be the target: gui = GUI(); background = gui.AddImage(); #background = GuiObject(gui); <-- Collected but not allowed background.ImageFile("bg.jpg"); background.Move(0, 0); ... How could I implement the AddImage function in order to be freed the constructed object at the end? Thanks in advance! All-the-best, Csaba

1 0

super() in Python/C
by Hrvoje Niksic 11 Mar '09

11 Mar '09

After the initial controversy regarding Python's super(), I feel that it's now fairly well-understood when it should be used and what problems it solves. (Even if not, this list is probably not the right medium for objections to super.) The one question I haven't seen covered is whether and how to use it from C. All of the Python/C code I've seen calls its base class(es) directly, typically by only invoking the method of their superclass in the C layout sense. This means that such code will call into the superclass twice in a diamond inheritance scenario. For low-level classes that are not expected to be multiply inherited this is not a problem. But in some cases we need to convert higher-level classes from Python to C for efficiency, either using Python/C, or a higher-level C++ wrapping. The classes use super() with good reason, and I'd like to avoid breaking them during conversion to C. Is there a documented way to use super() from C, other than instantiating PySuper_Type? Has anyone tried to do that?

2 1

Re: [capi-sig] (was Re: Problem with reference)
by pycnweb 03 Mar '09

03 Mar '09

2009-03-03 23:43:35，"Stefan Behnel" <python_capi(a)behnel.de> wrote： >Ken Hughes wrote: >> 1) Did anyone answer the original poster's question? > >Yes, two people (and one right in the first post, actually). > > >> 2) If this is going to persist as an OT thread, change the subject line? > >I think "problem with reference" isn't that far from a good subject. ;-) > >Stefan > >_______________________________________________ >capi-sig mailing list >capi-sig(a)python.org >http://mail.python.org/mailman/listinfo/capi-sig Thanks for everybody's answer. Cython is a good assistant for writing c/c++ extension, but I it is indispensable to master Python/C API also. :)

1 0

(was Re: Problem with reference)
by Ken Hughes 03 Mar '09

03 Mar '09

1) Did anyone answer the original poster's question? 2) If this is going to persist as an OT thread, change the subject line? Ken Stefan Behnel wrote: > Gustavo Carneiro wrote: > >> 2009/3/3 Stefan Behnel wrote: >> >>> Cython is (literally) not a wrapper generator as it will not generate a >>> wrapper for you. You have to write it yourself. Cython is a programming >>> language to write extension modules for CPython, as generic as that. >>> >> OK, but surely we can say that Cython is a code generator, or compiler. >> [...] >> It is more or less at the same level as Boost.Python. >> You also have to write the wrapper code using Boost.Python yourself... >> > > Except that Boost.Python does not optimise the code for you, simply > because it is a library, not a compiler. It doesn't know what called it > with what intention. The Cython compiler can extract a lot of information > from your code and it *will* use it to make your code run fast. For > example, calling a Cython implemented function is very fast compared to > normal Python, simply because we can adapt the generated code to the > specific signature of a function, instead of relying on generic argument > unpacking code. > > Stefan > > _______________________________________________ > capi-sig mailing list > capi-sig(a)python.org > http://mail.python.org/mailman/listinfo/capi-sig > >

2 1

Re: [capi-sig] Problem with reference
by Gustavo Carneiro 03 Mar '09

03 Mar '09

2009/3/3 Stefan Behnel <python_capi(a)behnel.de> > Gustavo Carneiro wrote: > > And Cython *is* a wrapper generator. > > Well, no, but PyBindGen is, now that you mention it. It looks a bit like a > FFI (like ctypes), but it generates the corresponding wrapper code, if I'm > not mistaken. Using it for anything but wrapping C/C++ code to make it > callable in Python would be futile. > > Cython is (literally) not a wrapper generator as it will not generate a > wrapper for you. You have to write it yourself. Cython is a programming > language to write extension modules for CPython, as generic as that. It > focuses on Python-like simplicity, C-like speed and easy interfacing with > both CPython and C (while better C++ and Fortran support is still being > fledged out). It is being used to write wrappers, but it is also being > used to write high-performance computational code, with or without > interfacing to external C libraries. In the second line, it's also heading > to become a fully-compliant Python compiler (a 1.0 goal), but that doesn't > belong here (just like the automatic-compile-on-import support for Python > files *wink*). OK, but surely we can say that Cython is a code generator, or compiler. So it's more generic than a wrapper generator. But it can fulfill the role of wrapper generator, even if it means writing more code than other tools for describing the same API. For me, wrapper is any C/C++ code that bindings Python to a C/C++ library. If Cython can generate that code, then Cython can also be considered a wrapper generator, or at least the engine for a wrapper generator. It is more or less at the same level as Boost.Python. You also have to write the wrapper code using Boost.Python yourself... > > > > > I clearly remember seeing (ugly) C > > code generated by Cython, before I decided to write PyBindGen. > > Let's not start a discussion about taste here. Readable, commented, easy > to debug C code is an obvious goal of the Cython project, simply because > its developers are those who debug it most of the time. That said, we > generally tell our users to look at the highlighted HTML page that Cython > generates of their source code, so that they can focus more easily on > those parts of the generated C code that are worth optimising. Having to > read the entire C code file just to see where things go wrong is not a > good idea. OK. I won't comment except to mention that I am glad the Cython project wants to generate readable code. Regards, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert

2 1

Re: [capi-sig] Problem with reference
by M.-A. Lemburg 03 Mar '09

03 Mar '09

On 2009-03-03 12:14, Stefan Behnel wrote: > Cython is not a wrapper generator. It's a programming language that sits right > between Python and C and generates code for the C-API of Python. I think that's where the misunderstanding lies: This list is about the Python C-API and not about generators or other helpers that provide ways of avoiding it :-) http://www.python.org/community/sigs/current/capi-sig/ IMHO, the list is about: * discussing ways of improving the Python C API * helping developers that have questions about the Python C API Suggesting to use Cython or any of the other available tools feels a bit like saying "avoid the Python C API wherever you can", which doesn't give the right impression to developers seeking help from this forum. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 03 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

2 1

Re: [capi-sig] Problem with reference
by M.-A. Lemburg 03 Mar '09

03 Mar '09

On 2009-03-03 10:38, Stefan Behnel wrote: > Hrvoje Niksic wrote: >> Stefan Behnel writes: >>> pycnweb wrote: >>>> I am now writing a python extension, but I confuse with the reference. >>> If you care more about working code than fighting confusion, Cython >>> might be worth a look. >> Stefan, please stop doing this. This list is about helping people >> using Python/C, not Cython advocacy. > > Where is the difference? The list would be called cython-sig otherwise :-) There are many other alternatives to approaching Python extension writing in C/C++: * use ctypes * use Boost.Python * use SWIG * use sip * use PyCXX * use PyRex/Cython * use Robin * ... (there are lots more) However, this list is about the layer underneath all of those. It's about the Python C API and there are many good reasons to use it directly rather than using one of the above wrappers or wrapper generators. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 03 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

3 3

Re: [capi-sig] Problem with reference
by Hrvoje Niksic 03 Mar '09

03 Mar '09

"Stefan Behnel" <python_capi(a)behnel.de> writes: > I take your point. Especially to a someone who has just started to > learn the C-API, my above statement might sound misleading. Thank you. Other than the advocacy thing :-), I very much appreciate your contributions to the list.

1 0