On 2018-04-02 12:39, INADA Naoki wrote:
> Thanks for writing such hard PEP.
> At first glance, it new type hierarchy seems OK.
> But I can't understand rational for new flags.
Which flags in particular do you mean? I just pushed an update
explaining the rationale of METH_ARG0_FUNCTION:
> And it's very difficult to estimate runtime and maintenance cost of
> the PEP, without draft implementation.
Runtime cost: the goal is no slowdowns at all.
Maintenance cost: IMHO, this PEP simplifies functions in CPython by
removing special classes like method_descriptor so the effect should
only be in the good sense.
> FASTCALL is introduced in recently version, and it make implementation
> I'm afraid that this PEP make it worse.
What do you mean? I am not making any changes to METH_FASTCALL.
I only mention it in my PEP to document it.
sometimes I need to use contextlib.close but over methods with a different
name, for example stop(), halt(), etc. For those cases I have to write my
own contextlib.close specialized version with a hard-coded method name.
I think adding a "method" argument to contextlib.close can be very useful:
def closing(thing, method="close"):
Or maybe something even more generic:
def calling(fn, *args, **kwargs):
On 2018-03-31 18:09, Steven D'Aprano wrote:
> It seems like a huge amount of work
What is a huge amount of work? Writing the PEP? Implementing the PEP?
Using the PEP? Adapting existing Python code to the PEP?
> Why isn't the answer to provide a hook to support introspection?
That is a lot easier said than done. How would you do that?
The problem is that multiple classes are involved, at least
"builtin_function_or_method" and "method_descriptor". So you'll end up
with at least 3 classes (those 2 plus the existing "function")
supporting introspection. With my proposal, this is implemented only once.
And do you expect users to implement those hooks or do you expect Python
to do it? If you want to do it in Python, you'll need to add a new class
anyway. That doesn't look simpler than my PEP.
That being said, if there is a general consensus that this is the right
thing to do, I'll go for it. However, I'm afraid that people will
complain that I'm complicating functions in Python even more.
Second: while introspection was the initial motivation, it does make
sense to unify built-in functions and Python functions. For example: why
are unbound methods just functions in Python classes but not in
If you are going to do some reorganization of function classes anyway,
you might as well do it properly. I claim that functions will be
*easier* to work with in Python when my PEP is accepted, both for the
end user as well as for the implementor of custom function classes.
> Seems to me that if you want a fast, exact (no subclasses) check, you
> should use "type(obj) is Class" rather than isinstance. If the *only*
> reason to prohibit subclassing is to make isinstance a bit faster,
> I don't think that's a good enough reason.
I didn't really mean "isinstance" literally, I was mostly thinking of
the C API. I agree that it's not clear.
Do you happen to know why the existing function classes in Python
disallow subclassing? I assumed that it was for exactly this reason.