On 2018-07-23 00:28, Guido van Rossum wrote:
> So does your implementation of the PEP result in a net increase or
> decrease of the total lines of code?
12 files changed, 918 insertions(+), 704 deletions(-)
That's a net increase, so there is no obvious win here. Still, I have
various excuses for this increased number of lines of code:
1. I'm adding more comments and lines containing only characters from
the set " {};". This accounts for about 60% in the increase in number of
lines of code. Clearly, this shouldn't count against me.
2. I still need to support some old ways of doing things. For backwards
compatibility, functions and methods are still defined using a
PyMethodDef. So I need to convert this old structure to the new
protocol. I also keep support for some functions that my PEP makes
obsolete, such as PyCFunction_Call(). All this requires code, but that
code is simple.
3. In a few cases, specialized code is replaced by general code. For
example, code that needs the __name__ of a function changes from
accessing a known field in a C structure (func->m_ml->ml_name) to an
actual Python attribute lookup. And Python code like
def __qualname__(func):
name = func.__name__
try:
parent_qualname = func.__parent__.__qualname__
except AttributeError:
return name
return str(parent_qualname) + "." + name
is conceptually pretty simple, but it becomes 37 lines of C code in my
implementation.
4. The PEP does actually add a completely new feature: the flag
CCALL_FUNCARG. That is something that I could easily remove for now, but
PEP 580 would be a lot less useful without it. So it's something that I
would certainly want to add in a later PEP anyway. It's also required
for PEP 573.
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