[Python-Dev] PEP 575 (Unifying function/method classes) update
J.Demeyer at UGent.be
Sun May 20 16:15:08 EDT 2018
On 2018-05-19 15:29, Nick Coghlan wrote:
> That's not how code reviews work, as their complexity is governed by the
> number of lines changed (added/removed/modified), not just the number of
> lines that are left at the end.
Of course, you are right. I didn't mean literally that only the end
result matters. But it should certainly be considered.
If you only do small incremental changes, complexity tends to build up
because choices which are locally optimal are not always globally
optimal. Sometimes you need to do some refactoring to revisit some of
that complexity. This is part of what PEP 575 does.
> That said, "deletes more lines than it
> adds" is typically a point strongly in favour of a particular change.
This certainly won't be true for my patch, because there is a lot of
code that I need to support for backwards compatibility (all the old
code for method_descriptor in particular).
Going back to the review of PEP 575, I see the following possible outcomes:
(A) Accept it as is (possibly with minor changes).
(B) Accept the general idea but split the details up in several PEPs
which can still be discussed individually.
(C) Accept a minimal variant of PEP 575, only changing existing classes
but not changing the class hierarchy.
(D) Accept some yet-to-be-written variant of PEP 575.
(E) Don't fix the use case that PEP 575 wants to address.
Petr Viktorin suggests (C). I am personally quite hesitant because that
only adds complexity and it wouldn't be the best choice for the future
maintainability of CPython. I also fear that this hypothetical PEP
variant would be rejected because of that reason. Of course, if there is
some general agreement that (C) is the way to go, then that is fine for me.
If people feel that PEP 575 is currently too complex, I think that (B)
is a very good compromise. The end result would be the same as what PEP
575 proposes. Instead of changing many things at once, we could handle
each class in a separate PEP. But the motivation of those mini-PEPs will
still be PEP 575. So, in order for this to make sense, the general idea
of PEP 575 needs to be accepted: adding a base_function base class and
making various existing classes subclasses of that.
More information about the Python-Dev