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 classes, not Python classes. Extension classes are not dynamic. When you implement tp_call in a given way, the user cannot change it. So if a class implements the C call protocol or the vectorcall protocol, callers can make assumptions about what that means. > PEP 579 is mainly a list of supposed flaws with the > 'builtin_function_or_method' class. > The general thrust of PEP 579 seems to be that builtin-functions and > builtin-methods should be more flexible and extensible than they are. I > don't agree. If you want different behaviour, then use a different > object. Don't try an cram all this extra behaviour into a pre-existing > object. I think that there is a misunderstanding here. I fully agree with the "use a different object" solution. This isn't a new solution: it's already possible to implement those different objects (Cython does it). It's just that this solution comes at a performance cost and that's what we want to avoid. > I'll reiterate that PEP 590 is more general than PEP 580 and that once > the callable's code has access to the callable object (as both PEPs > allow) then anything is possible. You can't can get more extensible than > that. I would argue the opposite: PEP 590 defines a fixed protocol that is not easy to extend. PEP 580 on the other hand uses a new data structure PyCCallDef which could easily be extended in the future (this will intentionally never be part of the stable ABI, so we can do that). I have also argued before that the generality of PEP 590 is a bad thing rather than a good thing: by defining a more rigid protocol as in PEP 580, more optimizations are possible. > PEP 580 has the same limitation for the same reasons. The limitation is > necessary for correctness if an object supports calls via `__call__` and > through another calling convention. I don't think that this limitation is needed in either PEP. As I explained at the top of this email, it can easily be solved by not using the protocol for Python classes. What is wrong with my proposal in PEP 580: https://www.python.org/dev/peps/pep-0580/#inheritance Jeroen.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4