On 2019-05-10 00:07, Petr Viktorin wrote:
METH_FASTCALL is currently not documented, and it should be renamed
before it's documented. Names with "fast" or "new" generally don't age
well.
Just to make sure that we're understanding correctly, is your proposal
to do the following:
- remove the
Petr Viktorin schrieb am 10.05.19 um 00:07:
> On 5/9/19 5:33 PM, Jeroen Demeyer wrote:
>> Maybe you misunderstood my proposal. I want to allow both for extra
>> flexibility:
>>
>> - METH_FASTCALL (possibly combined with METH_KEYWORDS) continues to work
>> as before. If you don't want to care about
On 5/9/19 5:33 PM, Jeroen Demeyer wrote:
On 2019-05-09 20:30, Petr Viktorin wrote:
The underlying C function should not need to know how to extract
"self" from the function object, or how to handle the argument
offsetting.
Those should be implementation details.
Maybe you misunderstood my
On 2019-05-09 20:30, Petr Viktorin wrote:
But, if you apply the robustness principle to vectorcallfunc, it
should accept empty tuples.
Sure, if the callee wants to accept empty tuples anyway, it can do that.
That's the robustness principle. But us *forcing* the callee to accept
empty tuples
On 2019-05-09 20:30, Petr Viktorin wrote:
The underlying C function should not need to know how to extract
"self" from the function object, or how to handle the argument
offsetting.
Those should be implementation details.
Maybe you misunderstood my proposal. I want to allow both for extra
On 2019-05-09 23:09, Brett Cannon wrote:
Any reason the above are all "Vectorcall" and not "VectorCall"? You seem
to potentially have that capitalization for "PyCall_MakeVectorCall" as
mentioned below which seems to be asking for typos if there's going to
be two ways to do it. :)
On 2019-05-09 20:30, Petr Viktorin wrote:
### Making things private
For Python 3.8, the public API should be private, so the API can get
some contact with the real world. I'd especially like to be able to
learn from
Cython's experience using it.
That would mean:
* _PyObject_Vectorcall
*
On Thu, May 9, 2019 at 11:31 AM Petr Viktorin wrote:
> PEP 590 is on its way to be accepted, with some details still to be
> discussed. I've rejected PEP 580 so we can focus on one place.
>
> Here are things we discussed on GitHub but now seem to agree on:
>
> * The vectorcall function's kwname
PEP 590 is on its way to be accepted, with some details still to be
discussed. I've rejected PEP 580 so we can focus on one place.
Here are things we discussed on GitHub but now seem to agree on:
* The vectorcall function's kwname argument can be NULL.
* Let's use `vectorcallfunc`, not
On 5/6/19 3:43 AM, Jeroen Demeyer wrote:
On 2019-05-06 00:04, Petr Viktorin wrote:
- Single bound method class for all kinds of function classes: This
would be a cleaner design, yes, but I don't see a pressing need. As
PEP 579 says, "this is a compounding issue", not a goal. As I recall,
that
On 5/6/19 4:24 AM, Jeroen Demeyer wrote:
Hello Petr,
Thanks for your time. I suggest you (or somebody else) to officially
reject PEP 580.
I'll do that shortly.
I hope that you are not taking this personally. PEP 580 is a good
design. PEP 590 even says that it's built on your ideas.
I
Hello Petr,
Thanks for your time. I suggest you (or somebody else) to officially
reject PEP 580.
I start working on reformulating PEP 590, adding some elements from PEP
580. At the same time, I work on the implementation of PEP 590. I want
to implement Mark's idea of having a separate
On 2019-05-06 00:04, Petr Viktorin wrote:
- Single bound method class for all kinds of function classes: This
would be a cleaner design, yes, but I don't see a pressing need. As
PEP 579 says, "this is a compounding issue", not a goal. As I recall,
that is the only major reason for CCALL_DEFARG.
Hello!
Sorry for the delay; PyCon is keeping me busy. On the other hand, I
did get to talk to a lot of smart people here!
I'm leaning toward accepting PEP 590 (with some changes still). Let's
start focusing on it.
As for the changes, I have these 4 points:
I feel that the API needs some contact
Hi Jeroen,
On 25/04/2019 3:42 pm, Jeroen Demeyer wrote:
On 2019-04-25 00:24, Petr Viktorin wrote:
I believe we can achieve
that by having PEP 590's (o+offset) point not just to function pointer,
but to a {function pointer; flags} struct with flags defined for two
optimizations:
What's the
On 2019-04-27 14:07, Mark Shannon wrote:
class D(C):
__call__(self, ...):
...
and then create an instance `d = D()` then calling d will have two
contradictory behaviours; the one installed by C in the function pointer
and the one specified by D.__call__
It's true that the
Hi Petr,
On 24/04/2019 11:24 pm, Petr Viktorin wrote:
So, I spent another day pondering the PEPs.
I love PEP 590's simplicity and PEP 580's extensibility. As I hinted
before, I hope they can they be combined, and I believe we can achieve
that by having PEP 590's (o+offset) point not just to
Hello,
after reading the various comments and thinking about it more, let me
propose a real compromise between PEP 580 and PEP 590.
My proposal is: take the general framework of PEP 580 but support only a
single calling convention like PEP 590. The single calling convention
supported would
On 4/25/19 10:42 AM, Jeroen Demeyer wrote:
On 2019-04-25 00:24, Petr Viktorin wrote:
I believe we can achieve
that by having PEP 590's (o+offset) point not just to function pointer,
but to a {function pointer; flags} struct with flags defined for two
optimizations:
What's the rationale for
On 2019-04-25 00:24, Petr Viktorin wrote:
I believe we can achieve
that by having PEP 590's (o+offset) point not just to function pointer,
but to a {function pointer; flags} struct with flags defined for two
optimizations:
What's the rationale for putting the flags in the instance? Do you
So, I spent another day pondering the PEPs.
I love PEP 590's simplicity and PEP 580's extensibility. As I hinted
before, I hope they can they be combined, and I believe we can achieve
that by having PEP 590's (o+offset) point not just to function pointer,
but to a {function pointer; flags}
On 2019-04-02 21:38, Mark Shannon wrote:
Hi,
On 01/04/2019 6:31 am, Jeroen Demeyer wrote:
I added benchmarks for PEP 590:
https://gist.github.com/jdemeyer/f0d63be8f30dc34cc989cd11d43df248
Thanks. As expected for calls to C function for both PEPs and master
perform about the same, as they
Hi,
On 01/04/2019 6:31 am, Jeroen Demeyer wrote:
I added benchmarks for PEP 590:
https://gist.github.com/jdemeyer/f0d63be8f30dc34cc989cd11d43df248
Thanks. As expected for calls to C function for both PEPs and master
perform about the same, as they are using almost the same calling
I added benchmarks for PEP 590:
https://gist.github.com/jdemeyer/f0d63be8f30dc34cc989cd11d43df248
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
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 language.
PEP 580 is meant for extension
25 matches
Mail list logo
