To design a new C API, I see 3 options: (1) add more functions to the existing Py_LIMITED_API (2) "fork" the current public C API: remove functions and hide as much implementation details as possible (3) write a new C API from scratch, based on the current C API. Something like #define newcapi_Object_GetItem PyObject_GetItem"? Sorry, but "#undef <private_function>" doesn't work. Only very few functions are defined using "#define ...".
I dislike (1) because it's too far from what is currently used in practice. Moreover, I failed to find anyone who can explain me how the C API is used in the wild, which functions are important or not, what is the C API, etc. I propose (2). We control how much changes we do at each milestone, and we start from the maximum compatibility with current C API. Each change can be discussed and experimented to define what is the C API, what we want, etc. I'm working on this approach for 1 year, that's why many discussions popped up around specific changes :-) Some people recently proposed (3) on python-dev. I dislike this option because it starts by breaking the backward compatibility. It looks like (1), but worse. The goal and the implementation are unclear to me. -- Replacing PyDict_GetItem() (specialized call) with PyObject_Dict() (generic API) is not part of my short term plan. I wrote it in the roadmap, but as I wrote before, each change should be discusssed, experimented, benchmarked, etc. Victor Le lun. 19 nov. 2018 à 12:02, M.-A. Lemburg <m...@egenix.com> a écrit : > > On 19.11.2018 11:53, Antoine Pitrou wrote: > > On Mon, 19 Nov 2018 11:28:46 +0100 > > Victor Stinner <vstin...@redhat.com> wrote: > >> Python internals rely on internals to implement further optimizations, > >> than modifying an "immutable" tuple, bytes or str object, because you > >> can do that at the C level. But I'm not sure that I would like 3rd > >> party extensions to rely on such things. > > > > I'm not even talking about *modifying* tuples or str objects, I'm > > talking about *accessing* their value without going through an abstract > > API that does slot lookups, indirect function calls and object unboxing. > > > > For example, people may need a fast way to access the UTF-8 > > representation of a unicode object. Without making indirect function > > calls, and ideally without making a copy of the data either. How do > > you do that using the generic C API? > > Something else you need to consider is creating instances of > types, e.g. a tuple. In C you will have to be able to put > values into the data structure before it is passed outside > the function in order to build the tuple. > > If you remove this possibility to have to copy data all the > time, losing the advantages of having a rich C API. > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Nov 19 2018) > >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > >>> Python Database Interfaces ... http://products.egenix.com/ > >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > ________________________________________________________________________ > > ::: We implement business ideas - efficiently in both time and costs ::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > http://www.malemburg.com/ > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
