Mailman 3 May 2019 - 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]How to access the various levels of runtime state (e.g. PyInterpreterState, _PyRuntimeState)?
by Eric Snow 24 May '19

24 May '19

In https://bugs.python.org/issue36710 Victor wants to move away from the _PyRuntime C global, instead passing the _PyRuntimeState around explicitly. I'm in favor of the general idea, but not on a case-by-case basis like this. I left a comment on that issue (https://bugs.python.org/msg340945) that explains my position in more detail. In retrospect, I should have just posted here. :) So I've copied that comment below, as-is. FYI, my intention is not to refuse Victor's objective in the issue. Rather, I want to make sure we have consensus on a valid broader objective on which to focus. This seemed like a perfect opportunity to start a discussion about it. -eric -------------------------- Status Quo ============ For simplicity sake, let's say nearly all the code operates relative to the 3 levels of runtime state: * global - _PyRuntimeState * interpreter - PyInterpreterState * thread - PyThreadState Furthermore, there are 3 groups of functions in the C-API: * context-sensitive - operate relative to the current Python thread * runtime-dependent - operate relative to some part of the runtime state, regardless of thread * runtime-independent - have nothing to do with CPython's runtime state Most of the C-API is context-sensitive. A small portion is runtime-dependent. A handful of functions are runtime-independent (effectively otherwise stateless helper functions that only happen to be part of the C-API). Each context-sensitive function relies on there being a "runtime context" it can use relative to the current OS thread. That context consists of the current (i.e. active) PyThreadState, the corresponding PyInterpreterState, and the global _PyRuntimeState. That context is derived from data in TSS (see caveats below). This group includes most of the C-API. Each runtime-dependent function operates against one or more runtime state target, regardless of the current thread context (or even if there isn't one). The target state (e.g. PyInterpreterState) is always passed explicitly. Again, this is only a small portion of the C-API. Caveats: * for context-sensitive functions, we get the global runtime state from the global C variable (_PyRuntime) rather than via the implicit thread context * for some of the runtime-dependent functions that target _PyRuntimeState, we rely on the global C variable All of this is the pattern we use currently. Using TSS to identify the implicit runtime context has certain benefits and costs: benefits: * sticking with the status quo means no backward incompatibility for existing C-extension code * easier to distinguish the context-sensitive functions from the runtime-dependent ones * (debatable) callers don't have to track, nor pass through, an extra argument costs: * extra complexity in keeping TSS correct * makes the C-API bigger (extra macros, etc.) Alternative ============= For every context-sensitive function we could add a new first parameter, "context", that provides the runtime context to use. That would be something like this: struct { PyThreadState *tstate; ... } PyRuntimeContext; The interpreter state and global runtime state would still be accessible via the same indirection we have now. Taking this alternative would eliminate the previous costs. Having a consistent "PyRuntimeContext *context" first parameter would maintain the easy distinction from runtime-dependent functions. Asking callers to pass in the context explicitly is probably better regardless. As to backward compatibility, we could maintain a shim to bridge between the old way and the new. About the C-global _PyRuntime ============================== Currently the global runtime state (_PyRuntimeState) is stored in a static global C variable, _PyRuntime. I added it at the time I consolidated many of the existing C globals into a single struct. Having a C global makes it easy to do the wrong thing, so it may be good to do something else. That would mean allocating a _PyRuntimeState on the heap early in startup and pass that around where needed. I expect that would not have any meaningful performance penalty. It would probably also simplify some of the code we currently use to manage _PyRuntime correctly. As a bonus, this would be important if we decided that multiple-runtimes-per-process were a desirable thing. That's a neat idea, though I don't see a need currently. So on its own it's not really a justification for dropping a static _PyRuntime. :) However, I think the other reasons are enough. Conclusions ==================== This issue has a specific objective that I think is premature. We have an existing pattern and we should stick with that until we decide to change to a new pattern. That said, a few things should get corrected and we should investigate alternative patterns for the context-sensitive C-API. As to getting rid of the _PyRuntime global variable in favor of putting it on the heap, I'm not opposed. However, doing so should probably be handled in a separate issue. Here are my thoughts on actionable items: 1. look for a better pattern for the context-sensitive C-API 2. clearly document which of the 3 groups each C-API function belongs to 3. add a "runtime" field to the PyInterpreterState pointing to the parent _PyRuntimeState 4. (maybe) add a _PyRuntimeState_GET() macro, a la PyThreadState_GET() 5. for context-sensitive C-API that uses the global runtime state, get it from the current PyInterpreterState 6. for runtime-dependent C-API that targets the global runtime state, ensure the _PyRuntimeState is always an explicit parameter 7. (maybe) drop _PyRuntime and create a _PyRuntimeState on the heap during startup to pass around

7 17

Do we need an option to leave the LC_CTYPE locale unchanged?
by Victor Stinner 20 May '19

20 May '19

Hi, I'm working on my PEP 587 "Python Initialization Configuration": https://www.python.org/dev/peps/pep-0587/ I just proposed to add a new "configure_locale" configuration parameter to leave the LC_CTYPE locale unchanged: https://bugs.python.org/issue36945 Right now, Python always calls setlocale(LC_CTYPE, "") on all platforms to set the LC_CTYPE locale to the user preferred locale. Is it a problem when Python is embedded in an application? Or am I trying to fix an artificial issue? :-) By the way, Nick Coghlan and me decided to disable LC_CTYPE locale coercion (PEP 538) and UTF-8 Mode (PEP 540) by default in Python 3.8. It should reduce the risk of mojibake. Victor -- Night gathers, and now my watch begins. It shall not end until my death.

2 3

[capi-sig]Call protocol: tuple/dict subclasses?
by Jeroen Demeyer 10 May '19

10 May '19

Dear C API lovers, I have a question about the usual args/kwargs call protocol (as used by PyObject_Call and tp_call): is the "args" tuple supposed to be of type exactly tuple or are tuple subclasses allowed? Same question for "kwargs" and dict. The documentation is not clear about this. I do know that calls from Python are done with an exact tuple and exact dict, but in C this is not so clear. For example, the implementation of _PyErr_CreateException uses PyTuple_Check(), not PyTuple_CheckExact(): static PyObject* _PyErr_CreateException(PyObject *exception, PyObject *value) { if (value == NULL || value == Py_None) { return _PyObject_CallNoArg(exception); } else if (PyTuple_Check(value)) { return PyObject_Call(exception, value, NULL); } else { return PyObject_CallFunctionObjArgs(exception, value, NULL); } } Also, the implementation of the call protocol has assertions of both forms: you see both assert(PyTuple_Check(args)) and assert(PyTuple_CheckExact(args)) and similar for dict. It seems pretty random whether or not an exact type check is done. I'm pretty sure that there are code paths that would result in an assertion failure because of this. So basically my question is: what is the right behavior? Given the implementation of the Python bytecode interpreter, I would be inclined to say that type checks should be exact. I'm noticing this because I'm working on an implementation of PEP 590. Jeroen.

4 4

capi-sig May 2019