Mailman 3 September 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]fixedint patch, proof of concept working now
by Neil Schemenauer 19 Sep '18

19 Sep '18

Hi, It has taken a fair amount of work but I have mostly gotten tagged pointers working for small ints (currently 63 bits on 64-bit platform). The configure option is --with-fixedint. I'm trying to release early and often. The whole test suite runs without crashing, which feels like some kind of milestone to me. The following tests still fail: test_ctypes test_fcntl test_fileio test_gdb test_inspect test_io test_repl test_socket test_sqlite test_unicode test_userstring Latest code in here: https://github.com/nascheme/cpython/tree/tagged_int Unfortunately, there is a net slowdown with the fixedint option enabled. Full PGO benchmarks from pyperformance are below. I'm hoping there is still some good work to be done reducing the number of times fixed ints need to heap allocated. I suspect that is why the pickle_list and pickle_dict are slower. I should also try to measure the memory usage difference. The fixedint version should use less RAM. Here is a Linux perf report for the pickle_list benchmark: http://python.ca/nas/python/perf-fixedint-pickle-list.txt The addition of the extra test + jmp instructions to INCREF/DECREF are hurting a fair bit. I'm not sure there is anything to be done there. Based on the Linux perf results, I have the suspicion that the extra instructions for INCREF/DECREF/_Py_TYPE are blowing up the size of _PyEval_EvalFrameDefault. I need to investigate that more. BTW, Linux perf is amazing. Anyone who does low-level optimization work should study it. I did consider trying to use a second tag for short strings. Not sure it will help too much as some quick analysis shows that only 25% of strings used by PyDict_GetItem are short enough to fit. This morning I dreamed up new idea: analyze normal Python programs and build a list of strings commonly used for PyDict_GetItem. They will be strings like "self", builtin functions names, etc. Then use a tagged pointer to hold these common strings. I.e. a tag to denote a string (or interned symbol, in Lisp speak) and an integer which is the offset into the fixed array of interned strings. The savings would have to come from avoiding the INCREF/DECREF accounting of refcounts on those strings. Instead of fixed set of strings, perhaps we could make the intern process dynamically allocate the tag IDs. We could have a specialized lookdict that works for dicts containing only interned strings. $ ./python -m perf compare_to -G ../cpython-profile-tagged-off/base4.json fixedint5.json --min-spee d 5 Slower (24): - pickle_list: 3.06 us +- 0.04 us -> 3.74 us +- 0.03 us: 1.22x slower (+22%) - pickle_dict: 22.2 us +- 0.1 us -> 26.2 us +- 0.2 us: 1.18x slower (+18%) - raytrace: 501 ms +- 5 ms -> 565 ms +- 6 ms: 1.13x slower (+13%) - crypto_pyaes: 113 ms +- 1 ms -> 126 ms +- 0 ms: 1.12x slower (+12%) - logging_silent: 210 ns +- 4 ns -> 234 ns +- 3 ns: 1.11x slower (+11%) - telco: 6.00 ms +- 0.09 ms -> 6.68 ms +- 0.14 ms: 1.11x slower (+11%) - float: 111 ms +- 2 ms -> 123 ms +- 1 ms: 1.11x slower (+11%) - nbody: 122 ms +- 1 ms -> 135 ms +- 2 ms: 1.10x slower (+10%) - mako: 17.1 ms +- 0.1 ms -> 18.8 ms +- 0.1 ms: 1.10x slower (+10%) - json_dumps: 12.3 ms +- 0.2 ms -> 13.5 ms +- 0.1 ms: 1.10x slower (+10%) - scimark_monte_carlo: 103 ms +- 2 ms -> 113 ms +- 1 ms: 1.10x slower (+10%) - pickle_pure_python: 467 us +- 3 us -> 508 us +- 6 us: 1.09x slower (+9%) - logging_format: 10.2 us +- 0.1 us -> 11.1 us +- 2.2 us: 1.09x slower (+9%) - chameleon: 9.27 ms +- 0.09 ms -> 10.1 ms +- 0.1 ms: 1.09x slower (+9%) - sqlalchemy_imperative: 30.4 ms +- 0.8 ms -> 32.9 ms +- 0.9 ms: 1.08x slower (+8%) - django_template: 122 ms +- 2 ms -> 131 ms +- 2 ms: 1.08x slower (+8%) - sympy_str: 184 ms +- 2 ms -> 198 ms +- 5 ms: 1.07x slower (+7%) - unpickle_pure_python: 368 us +- 5 us -> 394 us +- 9 us: 1.07x slower (+7%) - sympy_expand: 426 ms +- 10 ms -> 452 ms +- 12 ms: 1.06x slower (+6%) - sympy_sum: 90.4 ms +- 0.6 ms -> 96.0 ms +- 1.0 ms: 1.06x slower (+6%) - regex_compile: 181 ms +- 7 ms -> 192 ms +- 7 ms: 1.06x slower (+6%) - scimark_lu: 173 ms +- 6 ms -> 182 ms +- 5 ms: 1.05x slower (+5%) - genshi_xml: 62.7 ms +- 0.8 ms -> 66.1 ms +- 0.8 ms: 1.05x slower (+5%) - pickle: 9.11 us +- 0.13 us -> 9.59 us +- 0.06 us: 1.05x slower (+5%) Faster (2): - unpack_sequence: 49.1 ns +- 0.7 ns -> 45.0 ns +- 1.3 ns: 1.09x faster (-8%) - scimark_sparse_mat_mult: 3.75 ms +- 0.05 ms -> 3.47 ms +- 0.05 ms: 1.08x faster (-8%) Benchmark hidden because not significant (29): 2to3, chaos, deltablue, dulwich_log, fannkuch, genshi_text, go, hexiom, html5lib, json_loads, logging_simple, meteor_contest, nqueens, pathlib, pidigits, python_startup, python_startup_no_site, regex_dna, regex_effbot, regex_v8, richards, scimark_fft, scimark_sor, spectral_norm, sqlite_synth, sympy_integrate, tornado_http, unpickle, unpickle_list Ignored benchmarks (5) of ../cpython-profile-tagged-off/base4.json: sqlalchemy_declarative, xml_etree_generate, xml_etree_iterparse, xml_etree_parse, xml_etree_process Ignored benchmarks (4) of fixedint5.json: xml_etree_pure_python_generate, xml_etree_pure_python_iterparse, xml_etree_pure_python_parse, xml_etree_pure_python_process

4 4

[capi-sig]tagged pointer fixed integer experiment
by Neil Schemenauer 16 Sep '18

16 Sep '18

This is an experiment to exercise the new C-API we are trying to design. I would like it to be able to support tagged pointers. This requires PyObject* to be treated as an opaque pointer. Note, I'm not suggesting that we should used tagged pointers in CPython. Instead, I just want to see if the API will make it possible to do it. The logic is that some Python implementations might want to use tagged pointers. They would also like to provide the same C-API as CPython. So, it would be real nice if we don't make things really hard for them. The patch adding the actual tagged pointer type is quite trivial. There are a number of git commits preceeding it in order to make it trivial. Coccinelle has been useful. Some of my semantic patches > @@ > expression E; > @@ > > -E->ob_type > +Py_TYPE(E) > @@ > expression E, F; > @@ > > -Py_TYPE(E) = F > +Py_SET_TYPE(E, F) Run like: spatch --sp-file ob_type.cocci <C source files> To speed things up, I used grep to narrow down the set of files to process. Here is the source code for the fixed int cpython. There is a new builtin 'fixedint'. It doesn't do much yet but at least doesn't immediately crash. https://github.com/nascheme/cpython/tree/tagged_int

8 21

[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: No C API if it's not doable in Python
by Jeroen Demeyer 07 Sep '18

07 Sep '18

On 2018-09-07 14:47, Victor Stinner wrote: > Inside CPython, the core and builtin modules, micro-optimizations must > be used: abuse borrowed references, macros, access directly to all > fields of C structure, etc. > > But here I'm talking about the public C API used by third party extensions. Making a difference between "inside CPython" and "third party extensions" is a bad idea. Making such a difference would be problematic: 1. Complexity: we should not have two different C APIs. There should be just one, usable internally and externally. 2. Performance: if an optimization is important for CPython, then it's also important for third-party extensions. We don't want third-party code to be inherently slower than CPython itself. (this reminds me of PEP 580, regarding several internal optimizations which aren't available to third-party classes) Jeroen.

6 6

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer 07 Sep '18

07 Sep '18

On 2018-09-04 23:50, Victor Stinner wrote: > I would like to design a new C API without borrow references. So > Py_TYPE() should go, replaced by something else. I don't see the problem with Py_TYPE(). Consider it an accessor macro, just a nice way to access to ob_type field.

12 38

[capi-sig]PyUnicode C API
by Victor Stinner 07 Sep '18

07 Sep '18

On 07.09.2018 10:22, Victor Stinner wrote: > > I'm in discussion with PyPy developers, and they reported different > > APIs which cause them troubles: > > (...) > > * almost all PyUnicode API functions have to go according to them. > > PyPy3 uses UTF-8 internally, CPython uses "compact string" (array of > > Py_UCS1, Py_UCS2 or Py_UCS4 depending on the string content). > > https://pythoncapi.readthedocs.io/bad_api.html#pypy-requests Le ven. 7 sept. 2018 à 10:33, M.-A. Lemburg <mal(a)egenix.com> a écrit : > I'm -1 on removing the PyUnicode APIs. We deliberately created a > useful and very complete C API for Unicode. > > The fact that PyPy chose to use a different internal representation > is not a good reason to remove APIs and have CPython extension take > the hit as a result. It would be better for PyPy rethink the > internal representation or create a shim API which translates > between the two worlds. > > Note that UTF-8 is not a good internal representation for Unicode > if you want fast indexing and slicing. This is why we are using > fixed code units to represent the Unicode strings. The PyUnicode C API is not only an issue for PyPy, it's also an issue for CPython. When the PEP 393 has been implemented, suddly, most of the PyUnicode API has been directly deprecated: all functions using the now legacy Py_UNICODE* type... Python 3.7 still has to support both the legacy Py_UNICODE* API and the new "compact string" API. It makes the CPython code base way more complex that it should be: any function accepting a string is supposed to call PyUnicode_Ready() and handle error properly. I would prefer to be able to remove the legacy PyUnicodeObject type, to only use compact strings everywhere. Let me elaborate what are good and bad functions for PyUnicode. Example of bad APIs: * PyUnicode_IS_COMPACT(): this API really rely on the *current* implementation * PyUnicode_2BYTE_DATA(): should only be used internally, there is no need to export it * PyUnicode_READ() * Py_UNICODE_strcmp(): use Py_UNICODE which is an implementation detail Good API: * PyUnicode_Concat(): C API for str + str * PyUnicode_Split() * PyUnicode_FindChar() Border line: * PyUnicode_IS_ASCII(op): it's a O(1) operation on CPython, but it can O(n) on other implementations (like PyPy which uses UTF-8). But we also added str.isascii() in Python 3.7.... * PyUnicode_READ_CHAR() * PyUnicode_CompareWithASCIIString(): the function name announces ASCII but decodes the byte string from Latin1 :-) Victor

3 8

[capi-sig]Re: No C API if it's not doable in Python
by Jeroen Demeyer 07 Sep '18

07 Sep '18

On 2018-09-07 15:17, Victor Stinner wrote: > I'm not sure if we can hide some functions for > regular C extensions, but only give access to Cython? Which problem would that solve? If you're happy with Cython using "internal" functions, why shouldn't other C extensions use those same internal functions?

1 0

[capi-sig]No C API if it's not doable in Python
by Victor Stinner 07 Sep '18

07 Sep '18

Le ven. 7 sept. 2018 à 12:45, M.-A. Lemburg <mal(a)egenix.com> a écrit : > > On 07.09.2018 11:46, Victor Stinner wrote: > > I'm trying to remove functions from the C API which allow to do things > > which are not possible at the Python level: > > https://pythoncapi.readthedocs.io/bad_api.html#no-public-c-functions-if-it-… > > > > It's a request coming from PyPy developers. > > There are always things which you have to be able to do at the > C level but cannot do at the Python level and that's intentional, > since you're working at the C level and want to have direct > access to the data, avoiding copying things around all the > time and creating intermediate temporary objects or buffers for > this. Your motivation here is basically performance, am I right? From what I understood, such optimization in the short term becomes a high technical debt in the long term for PyPy, Gilectomy, and any other Python implementation. Inside CPython, the core and builtin modules, micro-optimizations must be used: abuse borrowed references, macros, access directly to all fields of C structure, etc. But here I'm talking about the public C API used by third party extensions. ... Sadly, I didn't work on this topic yet, so I would prefer to not go further in the discussion, since I have no concrete examples of issue :-) > You also want callbacks to work from both worlds (Python into > C and C into Python), or embed the interpreter, or provide new > ways of working with the existing objects, or work with > code in a way which bypasses the exception machinery (in C > you very often raise exceptions and catch them without the > exception object itself every being created). You should really replace "Python" (the language) with "CPython" in your paragraph. I would like to move away from the current CPython. Victor

3 3

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer 05 Sep '18

05 Sep '18

On 2018-09-05 15:19, Hugh Fisher wrote: > And this happens to be exactly what Apple did when they added tagged > pointers to Objective-C. They told programmers not to access objectptr->isa > directly, instead to use OBJECT_GETCLASS(objectptr). Then later they > started implementing some objects as tagged pointers, and only code > that hadn't been updated broke. OBJECT_GETCLASS was the "stable > ABI" This is a stable API, but I would guess not a stable ABI. Victor Stinner wants a stable ABI.

2 1

[capi-sig]Experiment Python without Py_TYPE()
by Victor Stinner 05 Sep '18

05 Sep '18

Hi, In my previous "Open questions about borrowed references" thread, I asked if it's an issue or not that Py_TYPE() returns a borrowed reference. It seems like most people say that it's not an issue. If you want to discuss if Py_TYPE() is an issue, please contribute to the other thread. Here I only want to share my results. Honestly, I'm still not 100% convinced that Py_TYPE() is an issue :-) I experimented anyway a C API without Py_TYPE(). I chose to add 3 functions/features: * ``Py_GetType()``: similar to ``Py_TYPE()`` but returns a strong reference * ``Py_TYPE_IS(ob, type)``: equivalent to ``Py_TYPE(ob) == type`` * ``%T`` format for ``PyUnicode_FromFormat()`` Most of the usage of Py_TYPE() are the following 5 patterns. For the last one, I'm not sure that the "N" format of Py_BuildValue() should stay since it's also based on borrowed reference. Replacing Py_TYPE() requires a lot of changes, and I made many copy/paste mistakes. If we chose to remove Py_TYPE(), we really need a tool to automate refactoring. Otherwise, the risk of introducing a regression is just too high and send the wrong signals to users. Dealloc:: Py_TYPE(self)->tp_free((PyObject *)self); becomes:: PyTypeObject *type = Py_GetType(self); type->tp_free((PyObject *)self); Py_DECREF(type); Size:: res = _PyObject_SIZE(Py_TYPE(self)) + self->allocated * self->ob_descr->itemsize; becomes:: PyTypeObject *type = Py_GetType(self); res = _PyObject_SIZE(type) + self->allocated * self->ob_descr->itemsize; Py_DECREF(type); Error:: PyErr_Format(PyExc_TypeError, "first argument must be a type object, not %.200s", Py_TYPE(arraytype)->tp_name); becomes:: PyErr_Format(PyExc_TypeError, "first argument must be a type object, not %T", arraytype); Py_BuildValue:: result = Py_BuildValue( "N(CO)O", Py_GetType(self), typecode, list, dict); becomes:: result = Py_BuildValue( "N(CO)O", Py_GetType(self), typecode, list, dict); Victor

1 0

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer 05 Sep '18

05 Sep '18

On 2018-09-05 13:49, Petr Viktorin wrote: > I'm not at a computer right now, but AFAIK if <class int>'s refcount > drops to zero, we still try to deallocate it, and that causes an > assertion and terminates the interpreter. You're right but that's besides the original point. If code uses refcounting correctly (regardless of using an "old" or "new" API), then the class int will never be deallocated.

4 3

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer 05 Sep '18

05 Sep '18

On 2018-09-05 15:20, Victor Stinner wrote: > PyObject *obj = create_object(); > PyTypeObject *type = Py_TYPE(obj); > Py_DECREF(obj); > /* ... */ > /* type is now a dangling pointer */ > > Do you consider that this example uses reference counting "correctly"? No because Py_TYPE() is known to return a borrowed reference. So, if you want to do anything with it besides immediately using it, you need to Py_INCREF() it.

1 0

[capi-sig]Re: static allocation of extension types
by Jeroen Demeyer 05 Sep '18

05 Sep '18

On 2018-09-05 14:51, Hugh Fisher wrote: > As of Python 3.6 a static type cannot be a subclass of a dynamic > type This is true, but I don't really know why. This was added by Serhiy Storchaka in https://bugs.python.org/issue22079 but without much rationale. I'm guessing that heap types are too dynamic to reliably subclass from, but I don't really know... If you really have good reasons for having an extension type subclassing a heap type, I would love to know them. Jeroen.

2 1

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer 05 Sep '18

05 Sep '18

On 2018-09-05 13:32, Petr Viktorin wrote: > Only the type object, <class int>, would be immortal. This is already the case. Extension types are statically allocated, so they are effectively immortal.

3 2

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer 04 Sep '18

04 Sep '18

On 2018-09-05 00:12, Victor Stinner wrote: > Examples of Py_TYPE() usage. My issue is that replacing Py_TYPE() with > a new function which increment the reference counter of the type would > make the code less straightforward. You misunderstood my question. Why would you want to replace Py_TYPE() with a new function which increments the reference counter of the type? It seems to me that you are proposing a solution in search of a problem...

1 0

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer 04 Sep '18

04 Sep '18

On 2018-09-04 23:28, Victor Stinner wrote: > Hi, > > Ah! I succeeded to get a dangling pointer to a deallocated type object > using Py_TYPE(). The example is designed to trigger the bug, but it > proves that it's important to hold a strong reference to the type when > using Py_TYPE(). Maybe it's not an issue for the normal case in the > wild, but at least my example provides that there is an issue in a > corner case which waits to bite you. What's your point really? It's known that Py_TYPE() returns a borrowed reference, so your example code is buggy. It shouldn't surprise anyone that borrowed references can crash CPython.

3 3

[capi-sig]Open questions about borrowed references
by Victor Stinner 04 Sep '18

04 Sep '18

Hi, I'm working on the implementation of my new C API. Modifying macros to use function calls is straighforward, but it seems like borrowed references is a big issue. Doc/data/refcounts.dat helps to discover a few functions and macros, but when writing a test suite on the C API, I found many more functions: Py_TYPE(), Py_SETREF(), PyList_SetItem(), etc. https://pythoncapi.readthedocs.io/bad_api.html#borrowed-references I see borrowed references as a threat to optimizations, because we don't know how long the caller use the return objected. For example, if a list of numbers is specialized to store numbers as 32 bit numbers, PyList_GetItem() has to create a temporary PyObject, but when should we destroy this temporary PyObject? Reference counting used "correctly" fits well with such temporary objects. For Py_TYPE(), I like the straighfoward "Py_TYPE(obj)->tp_name" to get the name of the object type. But is it an issue here that Py_TYPE() returns a borrowed reference? I see an issue if the object is the only instance of a type and there is no other reference to the type. Example: void test(PyObject *obj) { PyTypeObject *type = Py_TYPE(obj); Py_DECREF(obj); printf("name: %s\n", type->tp_name); } It's posible that Py_DECREF() releases indirectly the type and so that type becomes a dangling pointer, no? What about Py_SETREF(): is it safe to use it? The user has to increment manually the reference counter. API doesn't force to use borrowed references, am I right? Victor

2 2

[capi-sig]Re: New pythoncapi GitHub organization and creation of a test suite for the Python C API
by Jeroen Demeyer 03 Sep '18

03 Sep '18

On 2018-09-03 20:50, Brett Cannon wrote: > The worry of unintended issues due to Cython > happening to use an C API that's actually under test seems like a > reasonable worry. We're using Python scripts and Python classes to run the standard Python test suite and nobody seems to find that a problem...

3 2

[capi-sig]Re: New pythoncapi GitHub organization and creation of a test suite for the Python C API
by Jeroen Demeyer 03 Sep '18

03 Sep '18

On 2018-08-31 10:31, Victor Stinner wrote: > I don't wante to write unit tests with Cython, cffi or anything else, > because I really need very thin control on everything. You don't need "very thin control on *everything*". You need very thin control on specific parts of the testsuite. And that's the nice thing about Cython: you can easily shift the amount of control that you take. You can write the usual unittest classes and test_FOO methods where you don't care much about control but write fine-tuned C code (either using Cython syntax or C syntax) where you do want control. Of course you may have other reasons to not want Cython...

6 6

[capi-sig]New pythoncapi GitHub organization and creation of a test suite for the Python C API
by Victor Stinner 03 Sep '18

03 Sep '18

Hi, To be able to work on a fork of CPython, I decided to create a new GitHub organization: https://github.com/pythoncapi/ I didn't want to work on my personal fork of CPython (vstinner/cpython). The organization has a single member: me, but I invited Eric Snow, Barry Warsaw and Pablo Galindo. Tell me if you want to join! I moved my documentation there, the source of https://pythoncapi.readthedocs.io/ website: https://github.com/pythoncapi/pythoncapi/ And I just forked CPython: https://github.com/pythoncapi/cpython I will experiment to implement the new C API in this fork, to not bother the upstream CPython. I started with a very simple change, replace PyTuple_GET_ITEM() macro with a function call. I also started to write unit tests: https://github.com/pythoncapi/cpython/blob/pythoncapi/capi/tests/test_tuple… I quickly experimented to write my own C unit test framework, but I'm not really satisfied of the "verbose" API. I'm looking at googletest and Check, does someone have an experience with a C unit test framework? I don't wante to write unit tests with Cython, cffi or anything else, because I really need very thin control on everything. Victor

4 5