On 09/13/18 02:22, Jeroen Demeyer wrote: > On 2018-09-13 02:26, Petr Viktorin wrote: >> The reference to PEP 573 is premature. > > It seems to me that PEP 580 helps with the use case of PEP 573. In fact, > it implements part of what PEP 573 proposes. So I don't see the problem > with the reference to PEP 573. Even if the implementation of PEP 573 > changes, the problem statement will remain and that's what I'm referring > to. > >> If you agree I can >> summarize rationale for "parent", as much as it concerns 580. > > Sure. I still think that we should refer to PEP 573, but maybe we can > summarize it also in PEP 580. I want to make it clear that PEP 580 doesn't depend on 579. Reviewers don't need to agree with PEP 579 to accept 580. Here's my proposed rewording: https://github.com/python/peps/pull/775/files?short_path=b34f00e#diff-b34f00eeb75773c32f9b22fd7fee9771 >> # Using tp_print >> >> The tp_print gimmick is my biggest worry. >> AFAIK there's no guarantee that a function pointer and Py_ssize_t are >> the same size. > > I'm not actually claiming anywhere that it is the same size. Indeed, I was thinking ahead here. Backporting this to earlier versions of CPython will not be completely trivial, but let's leave it to Cython. >> # Descriptor behavior >> >> I'd say "SHOULD" rather than "MUST" here. The section describes how to >> implement expected/reasonable behavior, but I see no need to limit that. > > There *is* actually an important reason to limit it: it allows code to > make assumptions on what __get__ does. This enables optimizations which > wouldn't be possible otherwise. If you cannot be sure what __get__ does, > then you cannot optimize > > obj.method(x) > > to > > type(obj).method(obj, x) I see now. Yes, that's reasonable. >> "if func supports the C call protocol, then func.__set__ must not be >> implemented." -- also, __delete__ should not be implemented, right?. > > Indeed. I write Python but I think C API, so for me these are both > really tp_descr_set. > >> PyCCall_FASTCALL is not a macro, shouldn't it be named PyCCall_FastCall? > > What's the convention for that anyway? I assumed that capital letters > meant a "really know what you are doing" function which could segfault > if used badly. Well, I don't think that's a useful distinction either. This is C; pretty much anything can segfault when used badly. Macros tend to be "fast": Py_TYPE just gets a member of a struct; Py_INCREF just increments a number. METH_NOARGS is just a number. None of them are very dangerous. IMO, PyTuple_GET_ITEM is not uppercase because it's dangerous, but because it just reaches into memory. > For me, whether something is a function or macro is just an > implementation detail (which can change between Python versions) which > should not affect the naming. True. I'm not saying the convention is very strict or useful. >> # C API functions >> >> The function PyCFunction_GetFlags is, for better or worse, part of the >> stable ABI. We shouldn't just give up on it. I'm fine with documenting >> that it shouldn't be used, but for functions defined using >> PyCFunction_New etc. it should continue behaving as before. >> One solution could be to preserve the "definition time" METH_* flags in >> the 0xFFF bits of cc_flags and use the other bits for CCALL_*. > > I'm fine with that if you insist. However, it would be a silly solution > to formally satisfy the "stable ABI" requirement without actually helping. Yes, it's definitely very silly. But that's not a reason to break our promise to the users. After all it's called "stable ABI", not "useful ABI" :) > I agree with your other points that I didn't reply to and will make some > edits to PEP 580. Thank you!
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