Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

2018-06-17 Thread Jeroen Demeyer 

Hello,

I have been working on a slightly different PEP to use a new type slot 
tp_ccalloffset instead the base_function base class. You can see the 
work in progress here:


https://github.com/jdemeyer/PEP-ccall

By creating a new protocol that each class can implement, there is a 
full decoupling between the features of a class and between the class 
hierarchy (such coupling was complained about during the PEP 575 
discussion). So I got convinced that this is a better approach.


It also has the advantage that changes can be made more gradually: this 
PEP changes nothing at all on the Python side, it only changes the 
CPython implementation. I still think that it would be a good idea to 
refactor the class hierarchy, but that's now an independent issue.


Another advantage is that it's more general and easier for existing 
classes to use the protocol (PEP 575 on the other hand requires 
subclassing from base_function which may not be compatible with an 
existing class hierarchy).



Jeroen.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

2018-06-17 Thread Nick Coghlan 
On 17 June 2018 at 19:00, Jeroen Demeyer  wrote:
> Hello,
>
> I have been working on a slightly different PEP to use a new type slot
> tp_ccalloffset instead the base_function base class. You can see the work in
> progress here:
>
> https://github.com/jdemeyer/PEP-ccall
>
> By creating a new protocol that each class can implement, there is a full
> decoupling between the features of a class and between the class hierarchy
> (such coupling was complained about during the PEP 575 discussion). So I got
> convinced that this is a better approach.
>
> It also has the advantage that changes can be made more gradually: this PEP
> changes nothing at all on the Python side, it only changes the CPython
> implementation. I still think that it would be a good idea to refactor the
> class hierarchy, but that's now an independent issue.
>
> Another advantage is that it's more general and easier for existing classes
> to use the protocol (PEP 575 on the other hand requires subclassing from
> base_function which may not be compatible with an existing class hierarchy).

Ah, this looks *very* nice :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

2018-06-17 Thread Ronald Oussoren 



> On 17 Jun 2018, at 11:00, Jeroen Demeyer  wrote:
> 
> Hello,
> 
> I have been working on a slightly different PEP to use a new type slot 
> tp_ccalloffset instead the base_function base class. You can see the work in 
> progress here:
> 
> https://github.com/jdemeyer/PEP-ccall
> 
> By creating a new protocol that each class can implement, there is a full 
> decoupling between the features of a class and between the class hierarchy 
> (such coupling was complained about during the PEP 575 discussion). So I got 
> convinced that this is a better approach.
> 
> It also has the advantage that changes can be made more gradually: this PEP 
> changes nothing at all on the Python side, it only changes the CPython 
> implementation. I still think that it would be a good idea to refactor the 
> class hierarchy, but that's now an independent issue.
> 
> Another advantage is that it's more general and easier for existing classes 
> to use the protocol (PEP 575 on the other hand requires subclassing from 
> base_function which may not be compatible with an existing class hierarchy).

This looks interesting. Why did you add a tp_ccalloffset slot to the type with 
the actual information in instances instead of storing the information in a 
slot? 

Ronald

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Some data points for the "annual release cadence" concept

2018-06-17 Thread Ronald Oussoren 


> On 15 Jun 2018, at 13:00, Nick Coghlan  wrote:
> 
> On 14 June 2018 at 06:30, Ronald Oussoren  > wrote:
>> On 13 Jun 2018, at 15:42, Nick Coghlan > > wrote:
>> 
>> Yeah, pretty much - once we can get to the point where it's routine for 
>> folks to be building "abiX" or "abiXY" wheels (with the latter not actually 
>> being a defined compatibility tag yet, but having the meaning of "targets 
>> the stable ABI as first defined in CPython X.Y"), rather than feature 
>> release specific "cpXYm" ones, then a *lot* of the extension module 
>> maintenance pain otherwise arising from more frequent CPython releases 
>> should be avoided.
>> 
>> There'd still be a lot of other details to work out to turn the proposed 
>> release cadence change into a practical reality, but this is the key piece 
>> that I think is a primarily technical hurdle: simplifying the current 
>> "wheel-per-python-version-per-target-platform" community project build 
>> matrices to instead be "wheel-per-target-platform”.
> 
> This requires getting people to mostly stop using the non-stable ABI, and 
> that could be a lot of work for projects that have existing C extensions that 
> don’t use the stable ABI or cython/cffi/… 
> 
> That said, the CPython API tends to be fairly stable over releases and even 
> without using the stable ABI supporting faster CPython feature releases 
> shouldn’t be too onerous, especially for projects with some kind of 
> automation for creating release artefacts (such as a CI system).
> 
> Right, there would still be a non-zero impact on projects that ship binary 
> artifacts.
> 
> Having a viable stable ABI as a target just allows third party projects to 
> make the trade-off between the upfront cost of migrating to the stable ABI 
> (but then only needing to rebuild binaries when their own code changes), and 
> the ongoing cost of maintaining an extra few sets of binary wheel archives. I 
> think asking folks to make that trade-off on a case by case basis is 
> reasonable, whereas back in the previous discussion I considered *only* 
> offering the second option to be unreasonable.

I agree.  I haven’t seriously looked at the stable ABI yet, so I don’t know if 
there are reasons for now migrating to it beyond Py2 support and the effort 
required.  For my own projects (both public and not) I have some that could 
possibly migratie to the stable ABI, and some that cannot because they access 
information that isn’t public in the stable ABI. 

I generally still use the non-stable C API when I write extensions, basically 
because I already know how to do so. 

Ronald

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

2018-06-17 Thread Stefan Behnel 
Ronald Oussoren schrieb am 17.06.2018 um 14:50:
> Why did you add a tp_ccalloffset slot to the type with the actual information 
> in instances instead of storing the information in a slot? 

If the configuration of the callable was in the type, you would need a
separate type for each kind of callable. That would quickly explode. Think
of this as a generalised PyCFunction interface to arbitrary callables.
There is a function pointer and some meta data, and both are specific to an
instance.

Also, there are usually only a limited number of callables around, so
memory doesn't matter. (And memory usage would be a striking reason to have
something in a type rather than an instance.)

Stefan

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

2018-06-17 Thread Jeroen Demeyer 

On 2018-06-17 14:50, Ronald Oussoren wrote:

This looks interesting. Why did you add a tp_ccalloffset slot to the type with 
the actual information in instances instead of storing the information in a 
slot?


Think of built-in functions. Every built-in function is a different 
callable and calls a different C function. So it must be stored in the 
instances.


However, the case where all instances share a PyCCallDef is also 
possible: all instances would then simply have the same PyCCallDef pointer.



Jeroen.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

2018-06-17 Thread Ronald Oussoren 


> On 17 Jun 2018, at 16:31, Stefan Behnel  wrote:
> 
> Ronald Oussoren schrieb am 17.06.2018 um 14:50:
>> Why did you add a tp_ccalloffset slot to the type with the actual 
>> information in instances instead of storing the information in a slot? 
> 
> If the configuration of the callable was in the type, you would need a
> separate type for each kind of callable. That would quickly explode. Think
> of this as a generalised PyCFunction interface to arbitrary callables.
> There is a function pointer and some meta data, and both are specific to an
> instance.

That’s true for PyCFunction, but not necessarily as a general replacement for 
the tp_call slot.  I my code I’d basically use the same function pointer and 
metadata for all instances (that is, more like PyFunction than PyCFunction). 

> 
> Also, there are usually only a limited number of callables around, so
> memory doesn't matter. (And memory usage would be a striking reason to have
> something in a type rather than an instance.)

I was mostly surprised that something that seems to be a replacement for 
tp_call stores the interesting information in instances instead of the type 
itself. 

Ronald

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

2018-06-17 Thread INADA Naoki 
Hi Jeroen.

It's interesting, but I think we need reference implementation to compare
it's benefit with it's complexity.

Victor had tried to add `tp_fastcall` slot, but he suspended his effort
because
it's benefit is not enough for it's complexity.
https://bugs.python.org/issue29259

I think if your idea can reduce complexity of current special cases without
any performance loss, it's nice.

On the other hand, if your idea increase complexity, I doubt it's benefit.

Increasing performance of all Python defined methods + most of builtin
methods
affects total application performance because it covers most calls.
But calling callable object other than them are relatively rare.  It may
not affect
real world performance of most applications.

So, until I can compare it's complexity and benefits, I can say only "it's
interesting."

Regards,

-- 
INADA Naoki  
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

2018-06-17 Thread Jeroen Demeyer 

On 2018-06-18 03:34, INADA Naoki wrote:

Victor had tried to add `tp_fastcall` slot, but he suspended his effort
because
it's benefit is not enough for it's complexity.
https://bugs.python.org/issue29259


I has a quick look at that patch and it's really orthogonal to what I'm 
proposing. I'm proposing to use the slot *instead* of existing fastcall 
optimizations. Victor's patch was about adding fastcall support to 
classes that didn't support it before.



Jeroen.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

2018-06-17 Thread INADA Naoki 
I didn't meant comparing tp_fastcall and your PEP.

I just meant we need to compare complexity and benefit (performance),
and we need reference implementation for comparing.


On Mon, Jun 18, 2018 at 3:03 PM Jeroen Demeyer  wrote:

> On 2018-06-18 03:34, INADA Naoki wrote:
> > Victor had tried to add `tp_fastcall` slot, but he suspended his effort
> > because
> > it's benefit is not enough for it's complexity.
> > https://bugs.python.org/issue29259
>
> I has a quick look at that patch and it's really orthogonal to what I'm
> proposing. I'm proposing to use the slot *instead* of existing fastcall
> optimizations. Victor's patch was about adding fastcall support to
> classes that didn't support it before.
>
>
> Jeroen.
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>


-- 
INADA Naoki  
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com