[Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
Hello, Let me present PEP 579 and PEP 580. PEP 579 is an informational meta-PEP, listing some of the issues with functions/methods implemented in C. The idea is to create several PEPs each fix some part of the issues mentioned in PEP 579. PEP 580 is a standards track PEP to introduce a new "
Re: [Python-Dev] C-level calling
On 2018年06月20日 08:00, Stefan Behnel wrote: Just to add another bit of background on top of the current discussion, there is an idea around, especially in the scipy/big-data community, (and I'm not giving any guarantees here that it will lead to a PEP + implementation, as it depends on people's wor
Re: [Python-Dev] PEP 575 (Unifying function/method classes) update
On 19 June 2018 at 16:12, INADA Naoki wrote:>> On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer wrote:>>>> On 2018年06月18日 16:55, INADA Naoki wrote:>>> Speeding up most python function and some bultin functions was very>>> significant.>>> But I doubt making some 3rd party call 20% faster ca
Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
Hi Jeroen, On 2018年6月20日 10:53:18 +0200 Jeroen Demeyer wrote:> > PEP 579 is an informational meta-PEP, listing some of the issues with > functions/methods implemented in C. The idea is to create several PEPs > each fix some part of the issues mentioned in PEP 579.> > PEP 580 is a st
Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
On 2018年06月20日 16:09, Antoine Pitrou wrote: But there seems to be some complication on top of that: - PyCCall_FastCall() accepts several types for the keywords, even a dict; That is actually a *simplification* instead of a *complication*. Currently, there is a huge amount of code duplicatio
Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
On 2018年6月20日 16:32:09 +0200 Jeroen Demeyer wrote:> >> - there's CCALL_OBJCLASS and CCALL_SLICE_SELF which have, well,>>non-obvious behaviour (especially the latter), especially as it is>>conditioned on the value of other fields or flags > > It's actually quite obvious when
Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
On 2018年06月20日 16:42, Antoine Pitrou wrote: I'm wondering what amount of code and debugging is needed for, say, Cython or Numba to implement that protocol as a caller, without going through the C API's indirections (for performance). The goal is to have a really fast C API without a lot of indir
[Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
Hi, All. First of all, thank you Jeroen for writing nice PEPs. When I read PEP 579, I think "6. METH_FASTCALL is private and undocumented" should be solved first. I don't have any idea about changing METH_FASTCALL more. If Victor and Serhiy think so, and PyPy maintainers like it too, I want to m
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
Hi, I chose to make it private because I wasn't sure about the API. I was right: Serhiy removed keyword arguments from METH_FASTCALL, you now have to use METH_FASTCALL | METH_KEYWORDS to also pass keyword arguments ;-) I don't recall if this change was done in 3.7 or also in 3.6. FASTCALL has been
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
On 2018年6月20日 18:09:00 +0200 Victor Stinner wrote:> >> If we can't at Python 3.7, I think we should do it at 3.8. > > What's the rationale to make it public in 3.7? Can't it wait for 3.8?> The new PEPs target 3.8 anyway, no?> > IMHO it's too late for 3.7. Agreed with Victor. Also
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
2018年6月21日(木) 1:17 Antoine Pitrou :> On 2018年6月20日 18:09:00 +0200> Victor Stinner wrote:>>>>> If we can't at Python 3.7, I think we should do it at 3.8.>>>> What's the rationale to make it public in 3.7? Can't it wait for 3.8?>> The new PEPs target 3.8 anyway, no?>>>> IMHO
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
20.06.18 18:42, INADA Naoki пише: First of all, thank you Jeroen for writing nice PEPs. When I read PEP 579, I think "6. METH_FASTCALL is private and undocumented" should be solved first. I don't have any idea about changing METH_FASTCALL more. If Victor and Serhiy think so, and PyPy maintainer
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
2018年6月21日(木) 1:59 Serhiy Storchaka :> 20.06.18 18:42, INADA Naoki пише:>> First of all, thank you Jeroen for writing nice PEPs.>>>> When I read PEP 579, I think "6. METH_FASTCALL is private and> undocumented">> should be solved first.>>>> I don't have any idea about changing METH_FA
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
Serhiy Storchaka schrieb am 20.06.2018 um 18:56:> 20.06.18 18:42, INADA Naoki пише:>> I don't have any idea about changing METH_FASTCALL more.>> If Victor and Serhiy think so, and PyPy maintainers like it too, I want>> to make it public as soon as possible.> > I don't have objections against
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
On 2018年6月20日 at 09:49 INADA Naoki wrote:>> 2018年6月21日(木) 1:17 Antoine Pitrou :>>> On 2018年6月20日 18:09:00 +0200>> Victor Stinner wrote:>>>>>>> If we can't at Python 3.7, I think we should do it at 3.8.>>>>>> What's the rationale to make it public in 3.7? Can't it wait f
[Python-Dev] Intent to accept PEP 561 -- Distributing and Packaging Type Information
I have reviewed PEP 561 and I intend to accept it some time next week, unless significant discussion happens between now and then. The latest version of the PEP can be found at https://www.python.org/dev/peps/pep-0561/ PEP 561 solves a big problem for users of static type checkers like mypy and P
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
>> >> Even though it's private at 3.7, extension authors can start using it at>> their risk if we decide METH_FASTCALL is public in 3.8 without any change>> from 3.7.>>>> People can still wait for 3.8. Waiting 1.5 years for a feature is nothing> when the software you're talking about is a
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
On 2018年06月20日 17:42, INADA Naoki wrote: I don't have any idea about changing METH_FASTCALL more. If Victor and Serhiy think so, and PyPy maintainers like it too, I want to make it public as soon as possible. There are two different things here: The first is documenting METH_FASTCALL such that