Re: [Python-Dev] [PEP 576/580] Comparing PEP 576 and 580
On 2018-07-31 09:36, INADA Naoki wrote:
I want to see PoC of direct C calling.
To be honest, there is no implementation plan for this yet. I know that several people want this feature, so it makes sense to think about it. For me personally, the main open problem is how to deal with arguments which may be passed both as Python object or as native C type. For example, when doing a function call like f(1,2,3), it may happen that the first argument is really a Python object (so it should be passed as Python int) but that the other two arguments are C integers.
And I think PoC can be implemented without waiting PEP 580.
For one particular class (say CyFunction), yes. But this feature would be particularly useful for calling between different kinds of C code, for example between Numba and CPython built-ins, or between Pythran and Cython, ... That is why I think it should be implemented as an extension of PEP 580. Anyway, this is a different subject that we should not mix in the discussion about PEP 580 (that is also why I am replying to this specific point separately). Jeroen.
On Tue, Jul 31, 2018 at 5:46 PM Jeroen Demeyer
On 2018-07-31 09:36, INADA Naoki wrote:
I want to see PoC of direct C calling.
To be honest, there is no implementation plan for this yet. I know that several people want this feature, so it makes sense to think about it.
Yes. It will be the strong benefit of PEP 580.
For me personally, the main open problem is how to deal with arguments which may be passed both as Python object or as native C type. For example, when doing a function call like f(1,2,3), it may happen that the first argument is really a Python object (so it should be passed as Python int) but that the other two arguments are C integers.
I don't think it's the main point... At first time, we can just skip direct calling path and use normal Python call.
And I think PoC can be implemented without waiting PEP 580.
For one particular class (say CyFunction), yes. But this feature would be particularly useful for calling between different kinds of C code, for example between Numba and CPython built-ins, or between Pythran and Cython, ...
That is why I think it should be implemented as an extension of PEP 580.
Of course, finally it can be implemented based on PEP 580. But I said "Proof of Concept". Optimize only Cython-to-Cython case is enough for "Proof of Concept". PoC makes it easy to discuss concrete API design for cross implementation call.
Anyway, this is a different subject that we should not mix in the discussion about PEP 580 (that is also why I am replying to this specific point separately).
For me, this is the most important benefit of PEP 580. I can't split
it from PEP 580.
And I didn't say PoC is needed *before* accepting or discussing PEP 580.
I just meant PoC can be implemented without waiting PEP 580 accepted,
and I want see it early.
Any PEP won't be accepted in few month, because we don't have flow to
accept PEPs for now.
And I think Victor and Serhiy are key person about these PEPs, but I don't know
when they have enough time to review / discuss / make decision about these PEPs.
So it's worthless that waiting PEP accepted before start PoC.
--
INADA Naoki
participants (2)
-
INADA Naoki
-
Jeroen Demeyer