[Python-Dev] PEP 575 (Unifying function/method classes) update

[Jeroen Demeyer]

On 2018-05-15 18:36, Petr Viktorin wrote:
> Naturally, large-scale
> changes have less of a chance there.

Does it really matter that much how large the change is? I think you are 
focusing too much on the change instead of the end result.

As I said in my previous post, I could certainly make less disruptive 
changes. But would that really be better? (If you think that the answer 
is "yes" here, I honestly want to know).

I could make the code less different than today but at the cost of added 
complexity. Building on top of the existing code is like building on a 
bad foundation: the higher you build, the messier it gets. Instead, I 
propose a solid new foundation. Of course, that requires more work to 
build but once it is built, the finished building looks a lot better.

> With such a "finished product" PEP, it's hard to see if some of the
> various problems could be solved in a better way -- faster, more
> maintainable, or less disruptive.

With "faster", you mean runtime speed? I'm pretty confident that we 
won't lose anything there.

As I argued above, my PEP might very well make things "more 
maintainable", but this is of course very subjective. And "less 
disruptive" was never a goal for this PEP.

> It's also harder from a psychological point of view: you obviously
> already put in a lot of good work, and it's harder to waste that work if
> an even better solution is found.

I hope that this won't be my psychology. As a developer, I prefer to 
focus on problems rather than on solutions: I don't want to push a 
particular solution, I want to fix a particular problem. If an even 
better solution is accepted, I will be a very happy man.

What I would hate is that this PEP gets rejected because some people 
claim that the problem can be solved in a better way, but without 
actually suggesting such a better way.

> Is a branching class hierarchy, with quite a few new of flags for
> feature selection, the kind of simplicity we want?

Maybe yes because it *concentrates* all complexity in one small place. 
Currently, we have several independent classes 
(builtin_function_or_method, method_descriptor, function, method) which 
all require various forms of special casing in the interpreter with some 
code duplication. With my PEP, this all goes away and instead we need to 
understand just one class, namely base_function.

> Would it be possible to first decouple things, reducing the complexity,
> and then tackle the individual problems?

What do you mean with "decouple things"? Can you be more concrete?

> The class hierarchy still makes it hard to decouple the introspection
> side (how functions look on the outside) from the calling mechanism (how
> the calling works internally).

Any class who wants to profit from fast function calls can inherit from 
base_function. It can add whatever attributes it wants and it can choose 
to implement documentation and/or introspection in whatever way it 
wants. It can choose to not care about that at all. That looks very 
decoupled to me.

> Starting from an idea and ironing out the details it lets you (and, if
> since you published results, everyone else) figure out the tricky
> details. But ultimately it's exploring one path of doing things – it
> doesn't necessarily lead to the best way of doing something.

So far I haven't seen any other proposals...

> That's a good question. Maybe inspect.isfunction() serves too many use
> cases to be useful. Cython functons should behave like "def" functions
> in some cases, and like built-in functions in others.

 From the outside, i.e. user's point of view, I want them to behave like 
Python functions. Whether it's implemented in C or Python should just be 
an implementation detail. Of course there are attributes like __code__ 
which dive into implementation details, so there you will see the 
difference.

> before we change how inspect.isfunction ultimately behaves,
> I'd like to make its purpose clearer (and try to check how that meshes
> with the current use cases).

The problem is that this is not easy to do. You could search CPython for 
occurrences of inspect.isfunction() and you could search your favorite 
Python projects. This will give you some indication, but I'm not sure 
whether that will be representative.

 From what I can tell, inspect.isfunction() is mainly used as guard for 
attribute access: it implies for example that a __globals__ attribute 
exists. And it's used by documentation tools to decide that it should be 
documented as Python function whose signature can be extracted using 
inspect.signature().


Jeroen.