I just would want to say that I'm very happy to read the discussions
about the C API finally happening on python-dev :-) The discussion is
very interesting!
> C is really the lingua franca
Sorry, but why not writing the API directly in french?
Victor
_
On 30Nov2018 1133, Antoine Pitrou wrote:
On Fri, 30 Nov 2018 13:06:11 -0600
Neil Schemenauer wrote:
On 2018-11-29, Armin Rigo wrote:
...Also, although I'm discussing it here, I think the whole approach
would be better if done as a third-party extension for now, without
requiring changes to CPy
On Fri, 30 Nov 2018 13:06:11 -0600
Neil Schemenauer wrote:
> On 2018-11-29, Armin Rigo wrote:
> > ...Also, although I'm discussing it here, I think the whole approach
> > would be better if done as a third-party extension for now, without
> > requiring changes to CPython---just use the existing C
Hi Steve,
On 30/11/2018, Steve Dower wrote:
> On 29Nov2018 2206, Armin Rigo wrote:
>> On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote:
>>> quo. We continue to not be able to change CPython internals at all,
>>> since that will break people using option B.
>>
>> No? That will only break users if
On 2018-11-29, Armin Rigo wrote:
> ...Also, although I'm discussing it here, I think the whole approach
> would be better if done as a third-party extension for now, without
> requiring changes to CPython---just use the existing C API to
> implement the CPython version.
Hello Armin,
Thank you for
Steve Dower wrote:
> My proposed marketing pitch is: "rewrite your existing code to be
> forward-compatible today and faster in the future without more work, or
> be prepared to rewrite/update your source code for each CPython release
> to remain compatible with the low level API". The promise
On Fri, 30 Nov 2018 09:22:30 -0800
Steve Dower wrote:
>
> My proposed marketing pitch is: "rewrite your existing code to be
> forward-compatible today and faster in the future without more work, or
> be prepared to rewrite/update your source code for each CPython release
> to remain compatible
On 29Nov2018 2206, Armin Rigo wrote:
On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote:
quo. We continue to not be able to change CPython internals at all,
since that will break people using option B.
No? That will only break users if they only have an option-B
``foo.cpython-318m-x86_64-linux-
Hi,
On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote:
> quo. We continue to not be able to change CPython internals at all,
> since that will break people using option B.
No? That will only break users if they only have an option-B
``foo.cpython-318m-x86_64-linux-gnu.so``, no option-A .so and no
On 28Nov2018 2208, Armin Rigo wrote:
Hi Steve,
On Tue, 27 Nov 2018 at 19:14, Steve Dower wrote:
On 27Nov2018 0609, Victor Stinner wrote:
Note: Again, in my plan, the new C API would be an opt-in API. The old
C API would remain unchanged and fully supported. So there is no
impact on performanc
On Thu, Nov 29, 2018 at 5:10 PM Armin Rigo wrote:
> PS: on CPython could use ``typedef struct { PyObject *_obj; }
> PyHandle;``. This works like a pointer, but you can't use ``==`` to
> compare them.
And then you could have a macro or inline function to compare them,
simply by looking at that pr
Hi Steve,
On Tue, 27 Nov 2018 at 19:14, Steve Dower wrote:
> On 27Nov2018 0609, Victor Stinner wrote:
> > Note: Again, in my plan, the new C API would be an opt-in API. The old
> > C API would remain unchanged and fully supported. So there is no
> > impact on performance if you consider to use th
On Mon, Nov 26, 2018 at 4:10 PM Larry Hastings wrote:
> On 11/23/18 5:15 AM, Armin Rigo wrote:
>
> Also FWIW, my own 2 cents on the topic of changing the C API: let's
> entirely drop ``PyObject *`` and instead use more opaque
> handles---like a ``PyHandle`` that is defined as a pointer-sized C
>
On 27Nov2018 0609, Victor Stinner wrote:
Note: Again, in my plan, the new C API would be an opt-in API. The old
C API would remain unchanged and fully supported. So there is no
impact on performance if you consider to use the old C API.
This is one of the things that makes me think your plan is
Le mar. 27 nov. 2018 à 01:13, Larry Hastings a écrit :
> (...) I'm not convinced the nice-to-have of "you can't dereference the
> pointer anymore" is worth this runtime overhead.
About the general idea of a new C API.
If you only look at CPython in release mode, there is no benefit. But
you sho
On Mon, Nov 26, 2018 at 6:12 PM Eric V. Smith wrote:
> I thought the important part of the proposal was to have multiple
> PyHandles that point to the same PyObject (you couldn't "directly
> compare handles with each other to learn about object identity"). But
> I'll admit I'm not sure why this wo
On 2018-11-27 00:08, Larry Hastings wrote:
On 11/23/18 5:15 AM, Armin Rigo wrote:
Also FWIW, my own 2 cents on the topic of changing the C API: let's
entirely drop ``PyObject *`` and instead use more opaque
handles---like a ``PyHandle`` that is defined as a pointer-sized C
type but is not actual
On 11/26/2018 7:08 PM, Larry Hastings wrote:
On 11/23/18 5:15 AM, Armin Rigo wrote:
Also FWIW, my own 2 cents on the topic of changing the C API: let's
entirely drop ``PyObject *`` and instead use more opaque
handles---like a ``PyHandle`` that is defined as a pointer-sized C
type but is not actu
On 11/23/18 5:15 AM, Armin Rigo wrote:
Also FWIW, my own 2 cents on the topic of changing the C API: let's
entirely drop ``PyObject *`` and instead use more opaque
handles---like a ``PyHandle`` that is defined as a pointer-sized C
type but is not actually directly a pointer. The main difference
Armin Rigo schrieb am 26.11.18 um 06:37:
> On Sun, 25 Nov 2018 at 10:15, Stefan Behnel wrote:
>> Overall, this seems like something that PyPy could try out as an
>> experiment, by just taking a simple extension module and replacing all
>> increfs with newref assignments. And obviously implementing
On Fri, Nov 23, 2018 at 2:22 PM Armin Rigo wrote:
>
> Hi Hugo, hi all,
>
> On Sun, 18 Nov 2018 at 22:53, Hugh Fisher wrote:
> > I suggest that for the language reference, use the license plate
> > or registration analogy to introduce "handle" and after that use
> > handle throughout. It's short,
Hi,
On Sun, 25 Nov 2018 at 10:15, Stefan Behnel wrote:
> Overall, this seems like something that PyPy could try out as an
> experiment, by just taking a simple extension module and replacing all
> increfs with newref assignments. And obviously implementing the whole thing
> for the C-API
Just to
Hi Armin,
Armin Rigo schrieb am 25.11.18 um 06:15:
> On Sat, 24 Nov 2018 at 22:17, Stefan Behnel wrote:
>> Couldn't this also be achieved via reference counting? Count only in C
>> space, and delete the "open object" when the refcount goes to 0?
>
> The point is to remove the need to return the s
Hi Stefan,
On Sat, 24 Nov 2018 at 22:17, Stefan Behnel wrote:
> Couldn't this also be achieved via reference counting? Count only in C
> space, and delete the "open object" when the refcount goes to 0?
The point is to remove the need to return the same handle to C code if
the object is the same
Armin Rigo schrieb am 23.11.18 um 14:15:
> In PyPy we'd have a global table of
> "open objects", and a handle would be an index in that table; closing
> a handle means writing NULL into that table entry. No emulated
> reference counting needed: we simply use the existing GC to keep alive
> objects
On Fri, 23 Nov 2018 at 23:24, Armin Rigo wrote
(regarding opaque "handles" in the C API):
> The C API would change a lot, so it's not reasonable to do that in the
> CPython repo. But it could be a third-party project, attempting to
> define an API like this and implement it well on top of both CP
Armin Rigo wrote:
> The C API would change a lot, so it's not reasonable to do that in the
> CPython repo. But it could be a third-party project, attempting to
> define an API like this and implement it well on top of both CPython
> and PyPy. IMHO this might be a better idea than just changing
Hi Hugo, hi all,
On Sun, 18 Nov 2018 at 22:53, Hugh Fisher wrote:
> I suggest that for the language reference, use the license plate
> or registration analogy to introduce "handle" and after that use
> handle throughout. It's short, distinctive, and either will match
> up with what the programmer
28 matches
Mail list logo
