Mailman 3 May 2020 - 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

Mail l8st
by casperssidekick 10 Jul '21

10 Jul '21

Sent from my Verizon, Samsung Galaxy smartphone

2 1

Update on C API changes to hide implementation details
by Victor Stinner 27 May '20

27 May '20

Hi, I pushed many changes in Python 3.9 to hide implementation details: * Add getter and setter functions for PyFrameObject, PyThreadState and PyInterpreterState structures. Examples: PyFrame_GetCode() (frame->f_code) and PyThreadState_GetInterpreter() (tstate->interp); PyFrame_GetCode() returns a strong reference (not a borrowed reference). * Move private functions to the internal C API. * etc. See https://docs.python.org/dev/whatsnew/3.9.html#c-api-changes for the full list. My overall project is described in this draft PEP: https://github.com/vstinner/misc/blob/master/cpython/pep-opaque-c-api.rst I created multiple issues to prepare the C API to make more structures opaque: * PyGC_Head: https://bugs.python.org/issue40241 * PyObject: https://bugs.python.org/issue39573 * PyTypeObject: https://bugs.python.org/issue40170 * PyThreadState: https://bugs.python.org/issue39573 * PyInterpreterState: https://bugs.python.org/issue35886 (done in Python 3.8) Related to that, Dong-hee Na and me pushed changes to prevent using Py_TYPE(), Py_REFCNT() and Py_SIZE() as l-value. "Py_TYPE(obj) = new_type" must now be written "Py_SET_TYPE(obj, new_type);". I updated Cython for that: https://github.com/cython/cython/commit/63ab284df20cfe99638f3f352080648c8a3… Many changes are somehow backward incompatible. Some are more incompatible than others. It's not easy for me to estimate how many C extensions will be broken by these incompatible changes. So far, it was quite easy to update C extensions to Python 3.9.0 beta1. One project call directly PyImport_Cleanup() which was described as an "internal" function. This function was moved to the internal C API under _PyImport_Cleanup(). You should not call it directly! In case of big troubles, there is always the ability to revert some incompatible changes, to fix broken projects, before re-applying these changes. I know that these incompatible changes are annoying, but I consider that we have to go through this painful road to enhance (optimize) CPython, but also other Python implementations like PyPy, IronPython or GraalPython. The HPy project proposes a whole new C API written correctly from the beginning. It is a different approach, but it doesn't solve the problem of the big number of existing C extensions which will take several months or years to be ported to HPy. So far, HPy doesn't offer any automated conversion from the current C API to the new HPy C API. But my goal is that CPython C API and HPy C API will converge somehow in the long term. Each small change that I'm making is moving the current C API a little bit closer to HPy! By the way, use Cython for *new* C extension, don't use the C API directly! It's already said in the CPython C API documentation! These C API changes are targeting existing C extensions written with the C API ;-) Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0

capi-sig May 2020