[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13Apr2020 2308, André Malo wrote: For one thing, if you open up APIs for Cython, they're open for everybody (Cython being "just" another C extension). More to the point: The ABIs have the same problem as they have now, regardless how responsive the Cython developers are. Once you compiled the

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

Steve Dower wrote: > On 11Apr2020 0025, Antoine Pitrou wrote: > > On Fri, 10 Apr 2020 23:33:28 +0100 > > > > Steve Dower wrote: > >> On 10Apr2020 2055, Antoine Pitrou wrote: > >>> On Fri, 10 Apr 2020 19:20:00 +0200 > >>> > >>> Victor Stinner wrote: > Note: Cython and cffi should be preferr

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13Apr2020 2105, Chris Meyer wrote: How would I call a Python function from the C++ application that returns a Python object to C++ and then call a method on that Python object from C++? My specific example is that I create Python handlers for Qt windows and then from the Qt/C++ I call meth

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

Sorry that this is a bit off-topic. cffi would be a user of any new C API. I've tried to make sure ABI3 is supported in setuptools and wheel, with varying success. Apparently virtualenvs and Windows have problems. I'm excited about the possibility of a better C API and possibly ABI. __

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

> On Apr 13, 2020, at 11:26 AM, Daniel Holth wrote: > > Was it regular cffi or cffi's embedding API, which is used a bit differently > than regular cffi, that "seems to only solve a fraction of the problem"? Was > just playing around with the embedding API and was impressed. > > In Python: >

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

It can be done exactly as passing a void* when registering a C callback, and getting it passed back to your callback function. https://cffi.readthedocs.io/en/latest/ref.html#ffi-new-handle-ffi-from-handle https://bitbucket.org/dholth/kivyjoy/src/aaeab79b2891782209a1219cd65a4d9716cea669/kivyjoy/con

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

Was it regular cffi or cffi's embedding API, which is used a bit differently than regular cffi, that "seems to only solve a fraction of the problem"? Was just playing around with the embedding API and was impressed. In Python: @ffi.def_extern() def uwsgi_pyexample_init(): print("init called") re

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On Mon, Apr 13, 2020 at 9:00 AM Steve Dower wrote: > On 13Apr2020 1325, Paul Moore wrote: > > Personally, I'd say that "recommended 3rd party tools" reads as saying > > "if you want a 3rd party tool to build extensions, these are good (and > > are a lot easier than using the raw C API)". That's a

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

> On Apr 13, 2020, at 5:25 AM, Paul Moore wrote: > > On a related but different note, what is the recommended policy > (assuming it's not to use the C API) for embedding Python, and for > exposing the embedding app to Python as a C extension? My standard > example of this is the Vim interface to

[Python-Dev] Re: Do we need port some extension modules to the modules directory?

Eric Snow wrote: > In practice neither has been a problem over the years. However, it > does make discovery a bit more complicated, both for new contributors > and for tools. So I consider it at the least worth looking into the > value (and downsides, if any) of moving the seemingly out-of-place

[Python-Dev] Re: Do we need port some extension modules to the modules directory?

Skip Montanaro wrote: > > I notice some modules not in modules > > directory(for example: _warnings、marshal in python directory). Do we need > > port those > > modules to modules directory? > > > > I strongly suspect the answer is "no." Modules which aren't in the > Modules directory are built di

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13Apr2020 1325, Paul Moore wrote: Personally, I'd say that "recommended 3rd party tools" reads as saying "if you want a 3rd party tool to build extensions, these are good (and are a lot easier than using the raw C API)". That's a lot different than saying "we recommend that people writing C ex

[Python-Dev] Re: Do we need port some extension modules to the modules directory?

On Sun, Apr 12, 2020 at 8:36 AM Hai Shi wrote: > I notice some modules not in modules directory(for example: _warnings、marshal > in python directory). Do we need port those modules to modules directory? FWIW, this is something I've been meaning to look at for a while and is relatively high on my

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

> * Hide implementation details from the C API to be able to `optimize > CPython`_ and make PyPy more efficient. > * The expectation is that `most C extensions don't rely directly on > CPython internals`_ and so will remain compatible. > * Continue to support old unmodified C extensions by cont

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13/04/2020 11:17, Steve Dower wrote: On 11Apr2020 1156, Rhodri James wrote: On 10/04/2020 18:20, Victor Stinner wrote: Note: Cython and cffi should be preferred to write new C extensions. This PEP is about existing C extensions which cannot be rewritten with Cython. If this is true, the do

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On Mon, 13 Apr 2020 at 11:20, Steve Dower wrote: > > On 11Apr2020 1156, Rhodri James wrote: > > On 10/04/2020 18:20, Victor Stinner wrote: > >> Note: Cython and cffi should be preferred to write new C extensions. > >> This PEP is about existing C extensions which cannot be rewritten with > >> Cyth

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13Apr2020 1122, Steve Dower wrote: On 11Apr2020 0111, Victor Stinner wrote: Steve: the use case is to debug very rare Python crashes (ex: once every two months) of customers who fail to provide a reproducer. My *expectation* is that a debug build should help to reproduce the bug and/or provid

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13Apr2020 1157, Antoine Pitrou wrote: On Mon, 13 Apr 2020 11:35:34 +0100 Steve Dower wrote: and this code that they're using doesn't have any system dependencies that differ in debug builds (spoiler: they do). Are you talking about Windows? On non-Windows systems, I don't think there are

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On Mon, 13 Apr 2020 11:35:34 +0100 Steve Dower wrote: > > Neither Windows not macOS support fork (macOS only recently). Victor's argument: "fork() is not terrific with inline reference counts". My argument: people shouldn't generally use fork() anyway, because it has other issues. My statement

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 11Apr2020 0025, Antoine Pitrou wrote: On Fri, 10 Apr 2020 23:33:28 +0100 Steve Dower wrote: On 10Apr2020 2055, Antoine Pitrou wrote: On Fri, 10 Apr 2020 19:20:00 +0200 Victor Stinner wrote: Note: Cython and cffi should be preferred to write new C extensions. This PEP is about existing C

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 11Apr2020 1156, Rhodri James wrote: On 10/04/2020 18:20, Victor Stinner wrote: Note: Cython and cffi should be preferred to write new C extensions. This PEP is about existing C extensions which cannot be rewritten with Cython. If this is true, the documentation on python.org needs a serious

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 11Apr2020 0111, Victor Stinner wrote: Steve: the use case is to debug very rare Python crashes (ex: once every two months) of customers who fail to provide a reproducer. My *expectation* is that a debug build should help to reproduce the bug and/or provide more information when the bug happens

[Python-Dev] Re: Providing fix for modulefinder.py regression on Windows

> On 12 Apr 2020, at 21:49, Eric V. Smith wrote: > > On 4/12/2020 4:08 PM, Barry Scott wrote: >> >>> On 11 Apr 2020, at 16:28, Barry Scott >> > wrote: >>> >>> modulefinder.py does not open source files in "rb" which >>> prevents compile() from applying the encod