Mailman 3 November 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

Mail l8st
by casperssidekick 09 Jul '21

09 Jul '21

Sent from my Verizon, Samsung Galaxy smartphone

2 1

Comments on PEP 573 – Module state access from C extension modules
by Stefan Behnel 25 Nov '19

25 Nov '19

Hi all, and thank you to the authors of this well thought-out PEP. https://www.python.org/dev/peps/pep-0573/ I read through the latest version and found it in a very good and convincing shape. It has been resting for more than a year now, and some things happened along the way, most notably PEP 590, to which I think it should be adapted. Here are my comments. I find it a bit sad that state lookups in slot methods are disadvantaged compared to normal methods, given that their entire point is to provide a performance _benefit_. However, for the time being, we do not know how relevant and visible this will become in practice, so it is good that the PEP does not propose a new/real/complex solution to it for now. Instead, it resorts to the MRO lookup (which can always be done), and leaves any larger change open for the future, when we know better if there really is a problem to solve. Check from my side, this is the right trade-off. I like the idea of immutable exception types. I'm not entirely happy with the word "Prepare" vs. "New" in the function name "PyErr_PrepareImmutableException", which is described to be similar to "PyErr_NewExceptionWithDoc". I understand that it does not create a new type everytime you call it, but then, it also only prepares something the first time you call it. Can't say if there is a good way to express this behaviour, but "prepare" seems worse to me than "new" or "create" IMHO, not better. Section [1] is the one on extension type methods, which IMHO should be adapted to PEP 590. I think it should be based on the vectorcall/fastcall calling conventions and not take tuple and dict but C arrays as arguments. Alternatively, we could have two new signatures (old-style + new-style), but that feels like overkill. the fastcall signatures are easy enough to handle in C code, and in most cases easier than tuple+dict. The signature of PyCMethod should become (PyObject *obj, PyTypeObject *defining_class, PyObject *const *args, size_t nargs, PyObject *keywords) The descriptor special casing [2] in PEP 590 is also worth mentioning in the context of this PEP. As far as I can see it, the C method type should implement the vectorcall protocol, and then pass the call through to the underlying C function, adding the "defining_class" parameter along the way. I've written up a PR [3] to change the PEP in that direction. The "_PyMethodDef_RawFastCall*" functions may no longer need to be modified after this, I think. BTW, if there is "a new type PyCMethodObject", then there is probably also a PyTypeObject for it, right? That should be mentioned somewhere. The section on static/immutable exceptions [4] says "On deinitialization of the exception type, *exc will be set to NULL". What sets them to NULL? Under "Helpers", it says "PyType_GetModuleState … returns pointer to state of the module". I assume that this refers to the PEP-3121 module state, but an explicit reference would make it clearer. It also says in the same section that "When a type without a module is passed in, SystemError is set and NULL returned". Is that necessarily an exception case? Why not simply return NULL and let the user deal with it? I think the question is: is there a use case for getting the module state of an arbitrary type? If so, passing a type that does not have a module reference is fine and should not raise an exception. If that's not a use case, then it _might_ be worth informing the user about their misuse, or not. I don't know. What was the intention here? Finally, the reference link to the patch set of the implementation does not work for me. Maybe it should be this? https://github.com/Dormouse759/cpython/compare/master...Dormouse759:pep-c As you can see, I do not have any objections or major concerns about this PEP. Next, I'll look through the implementation, and would also like to see at least an attempt to implement it in Cython, to get an idea about how its usage would look in the general case. But apart from that, I can see that a lot of thinking has already gone into this PEP. Stefan [1] https://www.python.org/dev/peps/pep-0573/#passing-the-defining-class-to-ext… [2] https://www.python.org/dev/peps/pep-0590/#descriptor-behavior [3] https://github.com/python/peps/pull/1159 [4] https://www.python.org/dev/peps/pep-0573/#static-exceptions

4 17