Re: [Python-Dev] PEP 590 discussion

2019-04-27 Thread Mark Shannon
Hi Petr, On 24/04/2019 11:24 pm, Petr Viktorin wrote: On 4/10/19 7:05 PM, Jeroen Demeyer wrote: On 2019-04-10 18:25, Petr Viktorin wrote: Hello! I've had time for a more thorough reading of PEP 590 and the reference implementation. Thank you for the work! And thank you for the review! I'd

Re: [Python-Dev] PEP 590 discussion

2019-04-27 Thread Mark Shannon
Hi Jeroen, On 15/04/2019 9:38 am, Jeroen Demeyer wrote: On 2019-04-14 13:30, Mark Shannon wrote: PY_VECTORCALL_ARGUMENTS_OFFSET exists so that callables that make onward calls with an additional argument can do so efficiently. The obvious example is bound-methods, but classes are at least as im

Re: [Python-Dev] PEP 590 discussion

2019-04-26 Thread Jeroen Demeyer
On 2019-04-25 23:11, Petr Viktorin wrote: My thoughts are not the roadmap, of course :) I asked about methods because we should aware of the consequences when choosing between PEP 580 and PEP 590 (or some compromise). There are basically 3 different ways of dealing with bound methods: (A) p

Re: [Python-Dev] PEP 590 discussion

2019-04-25 Thread Petr Viktorin
On 4/25/19 5:12 AM, Jeroen Demeyer wrote: On 2019-04-25 00:24, Petr Viktorin wrote: PEP 590 defines a new simple/fast protocol for its users, and instead of making existing complexity faster and easier to use, it's left to be deprecated/phased out (or kept in existing classes for backwards compa

Re: [Python-Dev] PEP 590 discussion

2019-04-25 Thread Jeroen Demeyer
On 2019-04-25 00:24, Petr Viktorin wrote: PEP 590 defines a new simple/fast protocol for its users, and instead of making existing complexity faster and easier to use, it's left to be deprecated/phased out (or kept in existing classes for backwards compatibility). It makes it possible for future

Re: [Python-Dev] PEP 590 discussion

2019-04-24 Thread Petr Viktorin
On 4/10/19 7:05 PM, Jeroen Demeyer wrote: On 2019-04-10 18:25, Petr Viktorin wrote: Hello! I've had time for a more thorough reading of PEP 590 and the reference implementation. Thank you for the work! And thank you for the review! I'd now describe the fundamental difference between PEP 580

Re: [Python-Dev] PEP 590 discussion

2019-04-24 Thread Petr Viktorin
Hi Mark! See my more general reply; here I'll just tie loose ends with a few +1s. On 4/14/19 7:30 AM, Mark Shannon wrote: On 10/04/2019 5:25 pm, Petr Viktorin wrote: [...] PEP 590 is built on a simple idea, formalizing fastcall. But it is complicated by PY_VECTORCALL_ARGUMENTS_OFFSET and Py_

Re: [Python-Dev] PEP 590 discussion

2019-04-16 Thread Jeroen Demeyer
On 2019-04-03 07:33, Jeroen Demeyer wrote: Access to the class isn't possible currently and also not with PEP 590. But it's easy enough to fix that: PEP 573 adds a new METH_METHOD flag to change the signature of the C function (not the vectorcall wrapper). PEP 580 supports this "out of the box" b

Re: [Python-Dev] PEP 590 discussion

2019-04-15 Thread Jeroen Demeyer
On 2019-04-14 13:30, Mark Shannon wrote: PY_VECTORCALL_ARGUMENTS_OFFSET exists so that callables that make onward calls with an additional argument can do so efficiently. The obvious example is bound-methods, but classes are at least as important. cls(*args) -> cls.new(cls, *args) -> cls.__init__

Re: [Python-Dev] PEP 590 discussion

2019-04-14 Thread Mark Shannon
Hi, Petr On 10/04/2019 5:25 pm, Petr Viktorin wrote: Hello! I've had time for a more thorough reading of PEP 590 and the reference implementation. Thank you for the work! Overall, I like PEP 590's direction. I'd now describe the fundamental difference between PEP 580 and PEP 590 as: - PEP 580

Re: [Python-Dev] PEP 590 discussion

2019-04-11 Thread Brett Cannon
On Thu, Apr 11, 2019 at 5:06 AM Jeroen Demeyer wrote: > Petr, > > I realize that you are in a difficult position. You'll end up > disappointing either me or Mark... > > I don't know if the steering council or somebody else has a good idea to > deal with this situation. > Our answer was "ask Petr

Re: [Python-Dev] PEP 590 discussion

2019-04-11 Thread Jeroen Demeyer
Petr, I realize that you are in a difficult position. You'll end up disappointing either me or Mark... I don't know if the steering council or somebody else has a good idea to deal with this situation. Jeroen has time Speaking of time, maybe I should clarify that I have time until the en

Re: [Python-Dev] PEP 590 discussion

2019-04-11 Thread Petr Viktorin
On 4/11/19 1:05 AM, Jeroen Demeyer wrote: On 2019-04-10 18:25, Petr Viktorin wrote: Hello! I've had time for a more thorough reading of PEP 590 and the reference implementation. Thank you for the work! And thank you for the review! One general note: I am not (yet) choosing between PEP 580 an

Re: [Python-Dev] PEP 590 discussion

2019-04-10 Thread Jeroen Demeyer
On 2019-04-10 18:25, Petr Viktorin wrote: Hello! I've had time for a more thorough reading of PEP 590 and the reference implementation. Thank you for the work! And thank you for the review! I'd now describe the fundamental difference between PEP 580 and PEP 590 as: - PEP 580 tries to optimize

Re: [Python-Dev] PEP 590 discussion

2019-04-10 Thread Petr Viktorin
Hello! I've had time for a more thorough reading of PEP 590 and the reference implementation. Thank you for the work! Overall, I like PEP 590's direction. I'd now describe the fundamental difference between PEP 580 and PEP 590 as: - PEP 580 tries to optimize all existing calling conventions - P

Re: [Python-Dev] PEP 590 discussion

2019-04-02 Thread Jeroen Demeyer
In one of the ways to call C functions in PEP 580, the function gets access to: - the arguments, - "self", the object - the class that the method was found in (which is not necessarily type(self)) I still have to read the details, but when combined with LOAD_METHOD/CALL_METHOD optimization (avoidi

Re: [Python-Dev] PEP 590 discussion

2019-04-02 Thread Mark Shannon
Hi, On 02/04/2019 1:49 pm, Petr Viktorin wrote: On 3/30/19 11:36 PM, Jeroen Demeyer wrote: On 2019-03-30 17:30, Mark Shannon wrote: 2. The claim that PEP 580 allows "certain optimizations because other code can make assumptions" is flawed. In general, the caller cannot make assumptions about t

Re: [Python-Dev] PEP 590 discussion

2019-04-02 Thread Petr Viktorin
On 3/30/19 11:36 PM, Jeroen Demeyer wrote: On 2019-03-30 17:30, Mark Shannon wrote: 2. The claim that PEP 580 allows "certain optimizations because other code can make assumptions" is flawed. In general, the caller cannot make assumptions about the callee or vice-versa. Python is a dynamic langu