>
>
>> 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
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
On Wed, 20 Jun 2018 at 09:49 INADA Naoki wrote:
>
> 2018年6月21日(木) 1:17 Antoine Pitrou :
>
>> On Wed, 20 Jun 2018 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
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
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
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
2018年6月21日(木) 1:17 Antoine Pitrou :
> On Wed, 20 Jun 2018 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
On Wed, 20 Jun 2018 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
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
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
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
On Wed, 20 Jun 2018 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
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
Hi Jeroen,
On Wed, 20 Jun 2018 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
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
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
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
Victor Stinner schrieb am 19.06.2018 um 16:59:
> 2018-06-19 13:58 GMT+02:00 Jeroen Demeyer :
>> Personally, I think that you are exaggerating these issues.
>
> I'm not trying to convince you to abandon the idea. I would be happy
> to be able to use FASTCALL in more cases! I just tried to explain
18 matches
Mail list logo