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
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
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
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
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
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
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_
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
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__
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
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
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
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
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
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
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
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
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
18 matches
Mail list logo