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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to