[Jeremy Hylton] > Pyrex is intended for converting existing Python code to C, for > performance. (I think.) Here is how I see Pyrex, and why I have much interest in it. I do not see Pyrex as a tool whose main goal is converting existing Python code to C, yet to some extent, it could be used with this goal in head. It is a tool for the programmer to express various interfaces between C and Python, using a variant of the Python language augmented with C declarations, _instead_ of the more usual C language augmented with macros and an API. The fact that Pyrex produces C code along the road is only part of the internal mechanics, but is not much of practical interest to the programmer. Pyrex can be used to extend Python with C code, written in C for the circumstance, or to wrap pre-existing C libraries. Pyrex can also be used to embed Python functions, written and interpreted by Python, within what would otherwise be a pure C application. I would guess that Pyrex could also be used with Python only or (with proper care) with C only, and not to build an Python-C interface, but these cases are probably not goint to be usual for me. The same as it is generally easier and more comfortable to develop and debug an algorithm or program in Python than in C, would it be only because C forces you into many details of memory management intricacies, it is much more easier and more comfortable developing and debugging a Python-C interface using Pyrex than using more traditional ways: you concentrate on the interface without having to cautiously swim among reference counts and the various and numerous API functions or macros. A neat advantage at using Python instead of C to write your interface is that you are much less likely to have bugs. Pyrex knows how to break apart Python structures and how to rebuild them, it takes care of properly maintaining reference count invariants, etc. so as long as Pyrex is not itself buggy, your interface is really on the safe side, bug-wise. As Python-C interface bugs might be painful to track down, this is big incentive towards Pyrex. Being allowed to forget (or avoid learning) all the details of the C API is yet another good selling point for Pyrex: it would be a spoiling of resources having many members of a development team to learn the C API for Python, while I can expect everybody in a programmer team to know Pyrex, because the learning curve is so small. Pyrex is more democratic! :-) A final point, which looks important to me, is that any good wrapping of a pre-existing C library is best done while giving a Python flavour to the interface, would it be only for a nicer and natural object orientation. If the wrapping is done using C to express the interface, the effort of programming the interface in C while adding more Python-typical paradigms is complicated by the language distance between C and Python. But as Pyrex is very close to Python, Pyrex allows natural and speedy building of more proper interfaces. The Pyrex code itself, which holds the glue between C and Python, is exactly the right place for implementing that necessary layer meant to reshape the C facilities into Python ways. -- François Pinard http://www.iro.umontreal.ca/~pinard
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4