Mailman 3 July 2018 - capi-sig

ANN: expy 0.6.5 released!
by Yingjie Lan 16 Apr '22

16 Apr '22

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 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

C API equivalent to abc.ABCMeta.register?
by Daniel Stutzbach 02 Mar '22

02 Mar '22

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 10 Jan '22

10 Jan '22

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

[capi-sig]Adding an official (minimal) Cython-like tool.
by Eric Snow 09 Sep '18

09 Sep '18

Not that long ago Brett, Barry, and I were talking about how to get extension authors to move away from the C-API. Cython is the obvious choice, but it isn't an official tool nor does it necessarily make sense to make it one. Regardless, it would help all parties involved if there *were* an official tool that was part of CPython (i.e. in the repo). Cython could build on top of it and extension authors would be encouraged to use it or Cython. If such a thing makes sense, I figure we would follow the pattern set by asyncio (relative to twisted). -eric

6 12

[capi-sig]Re: Adding an official (minimal) Cython-like tool.
by Jeroen Demeyer 04 Aug '18

04 Aug '18

On 2018-07-31 18:42, Brett Cannon wrote: > Yes, what Eric is suggesting is a baseline tool like Cython be added to > Python itself so it becomes the minimum, common tool that we point all > extension authors to. You didn't answer Victor's "stupid question": we can already point extension authors to Cython. Why do we need a new tool which will very likely have less features than the already-existing Cython? > then we will have to provide an FFI compiler for people to use in at least > the simple cases. Cython is *not* an FFI tool. It can be used for FFI but that's just one of its many use cases.

6 6

[capi-sig]Re: Let's change to C API!
by Jeroen Demeyer 04 Aug '18

04 Aug '18

On 2018-07-31 14:52, Victor Stinner wrote: > For C extensions which use (1), what's the benefit of moving to (2)? Source compatibility between Python releases: the source code compiles and works the same way on all Python versions (above a certain minimum version).

3 3

[capi-sig]Let's change to C API!
by Victor Stinner 03 Aug '18

03 Aug '18

Hi, Last year, I gave a talk at the Language Summit (during Pycon) to explain that CPython should become 2x faster to remain competitive. IMHO all attempts to optimize Python (CPython forks) have failed because they have been blocked by the C API which implies strict constraints. I started to write a proposal to change the C API to hide implementation details, to prepare CPython for future changes. It allows to experimental optimization ideas without loosing support for C extensions. C extensions are a large part of the Python success. They are also the reason why PyPy didn't replace CPython yet. PyPy cpyext remains slower than CPython because PyPy has to mimick CPython which adds a significant overhead (even if PyPy developers are working *hard* to optimize it). I created a new to discuss how to introduce backward incompatible changes in the C API without breaking all C extensions: http://pythoncapi.readthedocs.io/ The source can be found at: https://github.com/vstinner/pythoncapi/ I would like to create a team of people who want to work on this project: CPython, PyPy, Cython and anyone who depends on the C API. Contact me in private if you want to be added to the GitHub project. I propose to discuss on the capi-sig mailing list since I would like to involve people from various projects, and I don't want to bother you with the high traffic of python-dev. Victor PS: I added some people as BCC ;-)

5 7

[capi-sig]Replacing Python C API with CFFI
by Simon Cross 02 Aug '18

02 Aug '18

Hello! Summary: It looks like fixing the Python C API is a lot of work and might fail, so I was wondering if it would be better to put effort into reducing the C API by making more use of CFFI within the Python standard library instead? Motivation: * It feels like the C API is currently very broad because it provides a second interface layer to a large chunk of the Python object space (in addition to the one visible to Python code). * I think it was Armin Rigo's observation when writing CFFI that there is a better API that already exists -- i.e. C types and function signatures. * If we're going to do a lot of work, would it not be better to push instead for moving towards CFFI as the interface between C and Python? I'm not sure that this is orthogonal to Victor's current proposal or not -- it might just be one route to achieving it. Advantages over the current route: * There's a clearer direction for people to head it, so it's easier to contribute. * A lot of work has already been done (e.g. it works for PyPy, a lot of libraries already exist that use it). Maybe Cython is an equally good option to CFFI in this scenario -- I don't know Cython though, so I have no deep opinion on that. Schiavo Simon

5 12

[capi-sig]Re: Replacing Python C API with CFFI
by Jeroen Demeyer 31 Jul '18

31 Jul '18

The Python/C API and CFFI are different things which solve (mostly) different problems. Briefly, the C API lets you access Python from C while CFFI lets you access C from Python. There are overlapping use cases, where you could replace the usage of the C API by CFFI. But that certainly won't work in general (at least, I don't see it).

1 0