Re: [Python-Dev] Need discussion for a PR about memory and objects

Responding to a few points out of order. On Mon, Nov 19, 2018 at 04:14:03PM -0800, Chris Barker via Python-Dev wrote: > I think being a bit more explicit about what properties an ID has, and how > the id() function works, and we may not need an anlogy at all, it's not > that difficult a concept.

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Mon., Nov. 19, 2018, 14:04 Neil Schemenauer On 2018-11-19, Antoine Pitrou wrote: > > There are important use cases for the C API where it is desired to have > > fast type-specific access to Python objects such as tuples, ints, > > strings, etc. This is relied upon by modules such as _json and

Re: [Python-Dev] Need discussion for a PR about memory and objects

On 11/19/2018 4:14 PM, Chris Barker via Python-Dev wrote: On Mon, Nov 19, 2018 at 1:41 AM Antoine Pitrou > wrote: I'd rather keep the reference to memory addressing than start doing car analogies in the reference documentation. I agree -- and any of the

Re: [Python-Dev] Need discussion for a PR about memory and objects

On Mon, Nov 19, 2018 at 1:41 AM Antoine Pitrou wrote: > I'd rather keep the reference to memory addressing than start doing car > analogies in the reference documentation. > I agree -- and any of the car analogies will probably be only valid in some jurisdictions, anyway. I think being a bit mo

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On 2018-11-19, Antoine Pitrou wrote: > There are important use cases for the C API where it is desired to have > fast type-specific access to Python objects such as tuples, ints, > strings, etc. This is relied upon by modules such as _json and _pickle, > and third-party extensions as well. Thank

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On 19/11/2018 15:08, Victor Stinner wrote: ... For me, the limited API should be functions available on all Python implementations. Does it make sense to provide PyFloat_Pack4() in ..., Jython, ... ? Or is it something more specific to CPython? I don't know the answer. I'd say it's a CPython thin

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On 2018-11-19, Victor Stinner wrote: > 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. One idea is to download a large sample of extension modules from PyPI and then analyze them with some aut

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

Hi Stefan, Le lun. 19 nov. 2018 à 13:18, Stefan Krah a écrit : > In practice people desperately *have* to use whatever is there, including > functions with underscores that are not even officially in the C-API. > > I have to use _PyFloat_Pack* in order to be compatible with CPython, Oh, I never

[Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

Victor Stinner wrote: > 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. In practice people desperately *have* to use whatever is there, including functions with underscores that are not even

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

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_Obj

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Mon, 19 Nov 2018 11:53:42 +0100 Antoine Pitrou wrote: > On Mon, 19 Nov 2018 11:28:46 +0100 > Victor Stinner wrote: > > I would expect that the most common source of speed up of a C > > extension is the removal of the cost of bytecode evaluation (ceval.c > > loop). > > Well, I don't. All pr

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On 19.11.2018 11:53, Antoine Pitrou wrote: > On Mon, 19 Nov 2018 11:28:46 +0100 > Victor Stinner 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

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Mon, 19 Nov 2018 11:28:46 +0100 Victor Stinner wrote: > I would expect that the most common source of speed up of a C > extension is the removal of the cost of bytecode evaluation (ceval.c > loop). Well, I don't. All previous experiments showed that simply compiling Python code to C code usin

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

Le lun. 19 nov. 2018 à 10:48, Antoine Pitrou a écrit : > If the C API only provides Python-level semantics, then it will > roughly have the speed of pure Python (modulo bytecode execution). > > There are important use cases for the C API where it is desired to have > fast type-specific access to P

Re: [Python-Dev] General concerns about C API changes

On Sun, 18 Nov 2018 13:53:54 -0800 Nathaniel Smith wrote: > On Sun, Nov 18, 2018 at 8:52 AM Stefan Behnel wrote: > > > > Gregory P. Smith schrieb am 15.11.18 um 01:03: > > > From my point of view: A static inline function is a much nicer modern > > > code > > > style than a C preprocessor macr

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Sun, 18 Nov 2018 16:53:19 +0100 Stefan Behnel wrote: > > So, in Cython, we use macros wherever possible, and often avoid generic > protocols in favour of type specialisations. We sometimes keep local copies > of C-API helper functions, because inlining them allows the C compiler to > strip dow

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Fri, 16 Nov 2018 09:46:36 -0800 Brett Cannon wrote: > > I think part of the challenge here (and I believe it has been brought up > elsewhere) is no one knows what kind of API is necessary for some faster VM > other than PyPy. To me, the only C API that would could potentially start > working t

Re: [Python-Dev] Need discussion for a PR about memory and objects

On Sun, 18 Nov 2018 22:32:35 +1000 Nick Coghlan wrote: > > Chris's initial suggestion was to use "license number" or "social > security number" (i.e. numbers governments assign to people), but I'm > thinking a better comparison might be to vehicle registration numbers, > since that analogy can be