Now that the discussion on PEP 576/580 has been opened again, let me
write something about the complexity of function calls (*), which is
probably the most frequently given reason against PEP 580.
An important fact is the following: *the status-quo is complex*.
Over time, many performance impr
Antoine Pitrou writes:
> We could proceed by consensus: the PEP author publicly proposes a PEP
> delegate, and if no core developer opposes, that person is officially
> accepted as delegate.
I think this is too decentralized. I think there should be enthusiasm
for the delegate, say two "secon
On Wed, 1 Aug 2018 09:05:52 -0700
Brett Cannon wrote:
> On Wed, 1 Aug 2018 at 07:47 Terry Reedy wrote:
>
> > On 8/1/2018 6:17 AM, Jeroen Demeyer wrote:
> > > On 2018-07-31 11:12, INADA Naoki wrote:
> > >> Any PEP won't be accepted in few month, because we don't have flow to
> > >> accept PEP
On Wed, 1 Aug 2018 at 07:47 Terry Reedy wrote:
> On 8/1/2018 6:17 AM, Jeroen Demeyer wrote:
> > On 2018-07-31 11:12, INADA Naoki wrote:
> >> Any PEP won't be accepted in few month, because we don't have flow to
> >> accept PEPs for now.
> >
> > Is that certain? I haven't been following the proces
On 8/1/2018 6:17 AM, Jeroen Demeyer wrote:
On 2018-07-31 11:12, INADA Naoki wrote:
Any PEP won't be accepted in few month, because we don't have flow to
accept PEPs for now.
Is that certain? I haven't been following the process discussions, so
I'm just asking the question. For example, given
On 2018-07-31 11:12, INADA Naoki wrote:
Any PEP won't be accepted in few month, because we don't have flow to
accept PEPs for now.
Is that certain? I haven't been following the process discussions, so
I'm just asking the question. For example, given that you are already
looking at PEP 580, wo
On 2018-07-31 10:07, Jeroen Demeyer wrote:
On 2018-07-31 09:36, INADA Naoki wrote:
[snip]
I would like to stress that PEP 580 was designed for maximum
performance, both today and for future extensions (such as calling with
native C types).
I don't know what the word *stress* mean here. (Sor
On Tue, Jul 31, 2018 at 9:55 PM Jeroen Demeyer wrote:
>
> On 2018-07-31 12:10, INADA Naoki wrote:
> > Surely, they should understand they must use CCALL_* flags instead of
> > METH_* flags when implementing fast-callable object.
>
> Yes indeed. But implementing a fast-callable object is quite
> sp
On 2018-07-31 12:10, INADA Naoki wrote:
After spent several days to read PEP 580 and your implementation, I think
I can implement it. I think it's not easy, but it's not impossible too.
The signature of "extended_call_ptr" in PEP 576 is almost the same as
the signature of a CCALL_FUNCARG|CCAL
On 2018-07-31 12:10, INADA Naoki wrote:
Surely, they should understand they must use CCALL_* flags instead of
METH_* flags when implementing fast-callable object.
Yes indeed. But implementing a fast-callable object is quite
specialized, not something that ordinary extension writers would care
On Tue, Jul 31, 2018 at 7:27 PM Antoine Pitrou wrote:
>
> On Tue, 31 Jul 2018 19:10:48 +0900
> INADA Naoki wrote:
> >
> > I said "So PEP 576/580 are needed only when implementing callable object".
> > I showed example "functools.partial or functools.lru_cache".
> >
> > Using FASTCALL for callable
On Tue, 31 Jul 2018 19:10:48 +0900
INADA Naoki wrote:
>
> I said "So PEP 576/580 are needed only when implementing callable object".
> I showed example "functools.partial or functools.lru_cache".
>
> Using FASTCALL for callable object, instead of tp_call is one of important
> goal
> of PEP 576
On Tue, Jul 31, 2018 at 6:14 PM Jeroen Demeyer wrote:
>
> On 2018-07-31 09:36, INADA Naoki wrote:
> > I think PEP 580 is understandable only for people who tried to implement
> > method objects.
>
> Is this really a problem? Do we expect that all Python developers can
> understand all PEPs, especi
On 2018-07-31 11:12, INADA Naoki wrote:
For me, this is the most important benefit of PEP 580. I can't split
it from PEP 580.
I want PEP 580 to stand by itself. And you say that it is already
complicated enough, so we should not mix native C calling into it.
PEP 580 is written to allow futu
On Tue, Jul 31, 2018 at 5:46 PM Jeroen Demeyer wrote:
>
> 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. I
On 2018-07-31 09:36, INADA Naoki wrote:
I think PEP 580 is understandable only for people who tried to implement
method objects.
Is this really a problem? Do we expect that all Python developers can
understand all PEPs, especially on a technical subject like this?
To give a different example
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
First of all, I'm sorry to I forgot change my mail title.
(I though about reserving one more slot for Cython for
further Cython-to-Cython call optimization, but I rejected
my idea because I'm not sure it really help Cython.)
On Mon, Jul 30, 2018 at 11:55 PM Jeroen Demeyer wrote:
>
> On 2018-07-
Jeroen Demeyer schrieb am 30.07.2018 um 16:40:
> On 2018-07-30 15:35, INADA Naoki wrote:
>> As repeatedly said, PEP 580 is very complicated protocol
>> when just implementing callable object.
>
> Can you be more concrete what you find complicated? Maybe I can improve the
> PEP to explain it more.
On 2018-07-30 15:35, INADA Naoki wrote:
As repeatedly said, PEP 580 is very complicated protocol
when just implementing callable object.
Can you be more concrete what you find complicated? Maybe I can improve
the PEP to explain it more. Also, I'm open to suggestions to make it
less complicate
As repeatedly said, PEP 580 is very complicated protocol
when just implementing callable object.
It is optimized for implementing custom method object, although
almost only Cython want the custom method type.
I'm not sure adding such complicated protocol almost only for Cython.
If CyFunction can b
On 2018-07-30 13:11, INADA Naoki wrote:
Like previous SageMath bench, this is caused by Cython's
specialization; __Pyx_PyObject_CallOneArg.
It specializing calling PyFunction and PyCFunction, but it doesn't
specialized for calling CyFunction.
Yes, I saw that too. But this is exactly what CPyth
Like previous SageMath bench, this is caused by Cython's
specialization; __Pyx_PyObject_CallOneArg.
It specializing calling PyFunction and PyCFunction, but it doesn't
specialized for calling CyFunction.
Cython can optimize both benchmark with binding, but without PEP 576 nor 580,
by adding callin
Hello all,
since my latest benchmark for PEP 580 [1] involved SageMath, which is
quite a big project, I instead propose a much simpler benchmark
involving mistune.
mistune [2] is a Markdown parser implemented in the Python language. It
optionally allows Cython compilation. It doesn't use any
On 2018-06-26 21:43, Mark Shannon wrote:
https://github.com/markshannon/pep-576
This actually looks close to Victor Stinner's bpo-29259. But instead of
storing the function pointer in the class, you're storing it in the
instance.
One concern that I have is that this might lead to code dupli
On 2018-06-26 21:43, Mark Shannon wrote:
https://github.com/markshannon/pep-576
Your version of PEP 576 looks very different from the "official" PEP 576 at
https://www.python.org/dev/peps/pep-0576/
So can you please make a pull request to
https://github.com/python/peps/pulls
Also feel free to
Hi all,
Just a reminder that PEP 576 still exists as a lightweight alternative
to PEP 575/580. It achieves the same goals as PEP 580 but is much smaller.
https://github.com/markshannon/pep-576
Unless there is a big rush, I would like to do some experiments as to
whether the new calling conve
We should take the discussion about how and where PEP discussions should be
hosted off this thread and list.
On Wed, May 23, 2018 at 6:59 AM, Nick Coghlan wrote:
> On 23 May 2018 at 05:47, Guido van Rossum wrote:
>
>> On Tue, May 22, 2018 at 10:07 AM, Steve Dower
>> wrote:
>>
>>> On 22May2018
On 23 May 2018 at 05:47, Guido van Rossum wrote:
> On Tue, May 22, 2018 at 10:07 AM, Steve Dower
> wrote:
>
>> On 22May2018 0741, Guido van Rossum wrote:
>>
>>> ISTR there are plenty of PEPs that never get posted to python-ideas
>>> because they are discussed on a separate list.
>>>
>>
>> There
For the record: the only reason that I replied on GitHub was because the
proposal was not yet posted (as far as I know) to any mailing list.
Typically, a post is made to a mailing list more or less at the same
time as creating the PEP. In this case, there was a delay of a few days,
maybe also
On Tue, May 22, 2018 at 10:07 AM, Steve Dower
wrote:
> On 22May2018 0741, Guido van Rossum wrote:
>
>> ISTR there are plenty of PEPs that never get posted to python-ideas
>> because they are discussed on a separate list.
>>
>
> There are often better venues for the initial discussion (such as
> s
On 22May2018 0741, Guido van Rossum wrote:
ISTR there are
plenty of PEPs that never get posted to python-ideas because they are
discussed on a separate list.
There are often better venues for the initial discussion (such as
security-sig, distutils-sig or datetime-sig), but I think that's
ort
On Tue, May 22, 2018 at 5:29 AM, Victor Stinner wrote:
> 2018-05-19 11:15 GMT+02:00 mark :
> > The PEP can be viewed here:
> > https://github.com/python/peps/blob/master/pep-0576.rst
> > (...)
> > P.S.
> > I'm happy to have discussion of this PEP take place via GitHub,
> > rather than the mailing
2018-05-19 11:15 GMT+02:00 mark :
> The PEP can be viewed here:
> https://github.com/python/peps/blob/master/pep-0576.rst
> (...)
> P.S.
> I'm happy to have discussion of this PEP take place via GitHub,
> rather than the mailing list, but I thought I would follow the conventional
> route for now.
On 2018-05-19 11:15, mark wrote:
PEP 576 aims to fulfill the same goals as PEP 575
(this is a copy of my comments on GitHub before this PEP was official)
**Performance**
Most importantly, changing bound methods of extension types from
builtin_function_or_method to bound_method will yield a p
mark schrieb am 19.05.2018 um 11:15:
> At the language summit this year, there was some discussion of PEP 575.
> I wanted to simplify the PEP, but rather than modify that PEP, Nick Coghlan
> encouraged me to write an alternative PEP instead.
>
> PEP 576 aims to fulfill the same goals as PEP 575, b
Hi,
At the language summit this year, there was some discussion of PEP 575.
I wanted to simplify the PEP, but rather than modify that PEP, Nick
Coghlan encouraged me to write an alternative PEP instead.
PEP 576 aims to fulfill the same goals as PEP 575, but with fewer
changes and to be fully
37 matches
Mail list logo
