Mailman 3 May 2012 - capi-sig

ANN: expy 0.6.5 released!
by Yingjie Lan April 16, 2022

April 16, 2022

EXPY is an express way to extend Python! EXPY provides a way to extend python in an elegant way. For more information and a tutorial, see: http://expy.sourceforge.net/ What's new: 1. Correct treatment of __init__ method. 2. Give warnings of missing Py_INCREF on appropriate special type methods. 3. Documentation update. Cheers, Yingjie

3 3

ANNOUNCE: PyBindGen 0.8
by Gustavo Carneiro March 10, 2022

March 10, 2022

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

C API equivalent to abc.ABCMeta.register?
by Daniel Stutzbach March 2, 2022

March 2, 2022

I'm the author of an extension module (blist) that provides a type that fits the MutableSequence API. Is there a canonical way for me to register the type as a MutableSequence from the C API? -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>

3 2

Software Development - Application Development - Game Development
by Gary Jan. 10, 2022

Jan. 10, 2022

You are receiving this email because we wish you to use our cost-effective IT services. We are a China based Custom Software Application Development provider. We offer full cycle custom software programming services, from product idea, software development to support and enhancement. We employ a large pool of software engineers coming from different backgrounds. We are able to balance product development efforts and project duration to your business needs. Core Services: Custom Application Development Custom Software Development iPhone Application Development iPad Application Development Mobile Application Development Android Mobile Application Development Soft Product Development Game Design & Development Game Testing & Quality Assurance Cloud Computing Solutions: CRM Software Application Development ERP Software Application Development Enterprise Portal Solution Sales Force Automation Solution Game Design & Development Knowledge Management Solution Workflow Management Solution SharePoint Development Services Microsoft Online Services Microsoft Azure Services Best regards, Gary ITVIATSA Software Development Contact: ibsoftware(a)yeah.net Pls send address to larryremove123(a)msn.com for remove

2 2

Re: [capi-sig] Creating type object dynamically in run-time
by Stefan Behnel May 11, 2012

May 11, 2012

Mateusz Loskot, 11.05.2012 11:38: > On 10 May 2012 18:58, Stefan Behnel wrote: >> Mateusz Loskot, 10.05.2012 18:58: >>> Long story short, I have a software system implemented in C/C++ which >>> provides public API. The API is not fixed, may change, so scripting >>> engines use provided means of reflection to inspect this API and >>> generate bindings on-fly. >>> I embedded Python in this system and now I'm using the mentioned >>> reflection mechanisms to discover API and generate Python extension >>> modules and types dynamically during run-time. >>> >>> I simply use the reflection mechanisms provided to iterate over >>> definitions (structures, functions, constants, etc.) of the public API >>> and I compose Python extension types grouping methods, etc. >> >> Interesting. So you're reflecting on a C/C++ API to dynamically export it >> to Python space? > > Yes, roughly, that's the idea. > >> Then I guess that your internal binding code is also >> rather generic, right? > > Let's describe it in simplified way: > There are intermediate Python extensions defined which bridge > communication between the C++ world and dynamically generated Python classes. > For instance, there is a car and car engine. > Now, there is 'base car engine' which defines common protocol for > possible behaviours. > The 'base car engine" is specified and known at compile time, > Next, there is variety of kinds of engines where each provide > subset of the well-specified behaviours. Polymorphism, indeed. > > So, those specific engines are dynamically generated in run-time > and they communicate with car through the statically defined 'base car > engine' protocol. Hmm, that sounds more like you'd want to use a common compile time interface for them statically instead, but I guess I'm just underestimating the requirements here. >> It won't be able to call the application code >> directly, for example, if it doesn't know the API at compile time. > > Yes, so there are 'base' extension types defined statically. Makes sense. >>> I can not use Cython, nor I can use tools like SWIG, Boost.Python. >>> The (C)Python is the only tool I can use. >> >> Also interesting. I wonder who would notice with which tool you have >> written your source code once it's compiled... > > I guess nobody. It's just I had not known Cython before I started. > Now, I have most of my implementation ready. Sure, fair enough. (Although you wouldn't be the first one who ends up rewriting C code in Cython.) > I also wouldn't want to introduce new dependencies > and as long as Cython is not guaranteed to be 100% compatible > drop-in replacement for Python 3.2+, then I'm afraid I can't use it. > The FAQ does not confirm it is > http://wiki.cython.org/FAQ#IsCythonaPythonimplementation.3F Ah, that's the misunderstanding then. It's not meant as a replacement of CPython, only as a replacement for writing C/C++ code using CPython's C-API. It generates C code that runs on top of CPython and thus integrates natively with both C/C++ code and Python code. So, basically, you get the best of both worlds (C and Python) without having to write the C part of it. Stefan

1 0

Re: [capi-sig] Creating type object dynamically in run-time
by Stefan Behnel May 11, 2012

May 11, 2012

Mateusz Loskot, 10.05.2012 18:58: > Long story short, I have a software system implemented in C/C++ which > provides public API. The API is not fixed, may change, so scripting > engines use provided means of reflection to inspect this API and > generate bindings on-fly. > I embedded Python in this system and now I'm using the mentioned > reflection mechanisms to discover API and generate Python extension > modules and types dynamically during run-time. > > I simply use the reflection mechanisms provided to iterate over > definitions (structures, functions, constants, etc.) of the public API > and I compose Python extension types grouping methods, etc. Interesting. So you're reflecting on a C/C++ API to dynamically export it to Python space? Then I guess that your internal binding code is also rather generic, right? It won't be able to call the application code directly, for example, if it doesn't know the API at compile time. > I can not use Cython, nor I can use tools like SWIG, Boost.Python. > The (C)Python is the only tool I can use. Also interesting. I wonder who would notice with which tool you have written your source code once it's compiled... Stefan

2 1

Re: [capi-sig] Creating type object dynamically in run-time
by Stefan Behnel May 11, 2012

May 11, 2012

Mateusz Loskot, 10.05.2012 19:13: > On 10 May 2012 17:39, Stefan Behnel wrote: >> What you'd do next is to initialise your types in the module (or let >> CPython do it for you through the inittab) > > I'm not sure I completely understand it. > I assume that executing these two lines, > in context of the module: > > const char* c = "class A(object):\n\tpass"; > PyRun_StringFlags(c, Py_file_input, d, d, NULL); > > creates complete and initialised A class within this module. > Doesn't it? Yes, it does. What I meant what: if you want to let the dynamically generated Python classes inherit from your extension types, then initialise the extension types before hand so that they turn up in the module dict and your Python code can use them normally as base types. Stefan

2 1

Re: [capi-sig] Creating type object dynamically in run-time
by Stefan Behnel May 10, 2012

May 10, 2012

Mateusz Loskot, 10.05.2012 18:17: > On 10 May 2012 14:55, Mateusz Loskot wrote: >> On 10 May 2012 14:01, Stefan Behnel wrote: >>> You can execute any Python code from your C code. Look for the >>> PyRun_*() functions. >> >> Do you mean something similar to this approach? >> >> /* dynamically generated lengthy class definition */ >> const char* c = "class A(object): pass"; >> >> PyObject* class_a = PyRun_StringFlags(c, ...); >> PyObject_SetAttrString(module, "A", class_a) > > The pseudo-code above is incorrect. > I have come up with the following example of dynamically > generating new Python class, indirectly through script using class keyword. > Such dynamically created class is added to module dictionary: > > /* error checks removed for brevity */ > > static PyModuleDef embmodule = { ... }; > > PyInit_emb(void) > { > PyObject* m = PyModule_Create(&embmodule); > PyObject* d = PyModule_GetDict(m); > > /* Required to allow 'class' use in context of module which is > not yet complete and ready. Otherwise, error is thrown: > ImportError: __build_class__ not found > */ > PyObject* builtins = PyEval_GetBuiltins(); > PyDict_SetItemString(d, "__builtins__", builtins); > > /* Python class is dynamically generated */ > const char* c = "class A(object):\n\tpass"; /* sample class */ > > /* Create object for A class, automatically added to the module > dictionary as noddy.A */ > PyRun_StringFlags(c, Py_file_input, d, d, NULL); You want to take the result here, if only to decref it. What you'd do next is to initialise your types in the module (or let CPython do it for you through the inittab) and then let the Python classes inherit from them, stick C methods into them, etc. > return m; > } > > This approach works well. > If anyone noticed a problem or there is better way to do the same, > please let me know. Looks ok to me. Here's the equivalent code in Cython: class A(object): pass (except that it executes faster because it doesn't run through the Python parser and interpreter at runtime, but I don't think that matters much at module init time). Stefan

2 1

Re: [capi-sig] Creating type object dynamically in run-time
by Mateusz Loskot May 10, 2012

May 10, 2012

On 10 May 2012 17:38, Campbell Barton <ideasman42(a)gmail.com> wrote: > If speed of class creation is important (as it is for us). suggest to > call type directly rather then evaluating a string every time and > executing it - this is one way. > > > /* always use O not N when calling, N causes refcount errors */ > newclass = PyObject_CallFunction((PyObject *)&PyType_Type, (char > *)"s(O) {sss()}", > idname, py_base_class, > "__module__", "bpy.types", "__slots__"); > > which is like doing this in python... > > type(idname, (py_base_class, ), dict(__module__="bpy.types", __slots__=())) Campbell, Thanks for the hint. It's good to know how the type() should be called from C. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [capi-sig] Creating type object dynamically in run-time
by Stefan Behnel May 10, 2012

May 10, 2012

Mateusz Loskot, 10.05.2012 15:55: > On 10 May 2012 14:01, Stefan Behnel wrote: >> Note that this is even easier in Cython, where you write Python code anyway >> (instead of C code). > > Yes, I looked at the Cython docs. > Unfortunately, I can't use it. I have to stick to Python 3.2 dist. Cython works perfectly with Py3.2, even with the latest 3.3-pre and Python 2.4 and later as well. Helps you write portable code. >>> However, I'd really like to learn canonical means of generating extension types >>> dynamically using plain Python C API. >>> Long story short, I assume I'm looking for Python C API equivalent of >>> using type() function. >> >> Then call type(). > > It's possible, certainly. > But, is there any plain C equivalent, perhaps using PyType_Type > and the Descriptor Objects? > (Why purpose and usage of the Descriptor Objects are not documented?.) > I'm seeking for confirmation, if such approach would be close to the > type() function. > > To summary: > > 1) > It seems to be that generating script with Python classes in textual form > and then using Python C API like PyRun_StringFlags, etc. > is the recommended approach It's certainly much easier than doing everything in C. > 2) > There is approach based on direct call to type() function > using Python C API. > > 3) > Is there third option possible which replaces the 2nd's type() call > with chain of plain Python C API calls? > I know there are pros/cons related to amount of code, maintenance hassle, > code complexity, and such. but it is not related to my question really. I don't know what the best way is here. However, I really wonder what you are trying to achieve. If I was to implement an interface for an embedded Python runtime, I'd much rather focus on the design of the user level API that I'm exposing than the details of the low-level interface implementation. (But then again, I'd leave those mostly to Cython, so if you prefer doing them yourself, you'll have to jump through some more hoops, obviously.) Stefan

2 1