base_function

The classbase_functionbecomes a new base class for all function types. It is based on the existingbuiltin_function_or_methodclass, but with the following differences and new features:

1. It acts as a descriptor implementing__get__to turn a function into a method ifm_selfisNULL. Ifm_selfis notNULL, then this is a no-op: the existing function is returned instead.
2. A new read-only attribute__parent__,represented in the C structure asm_parent. If this attribute exists, it represents the defining object. For methods of extension types, this is the defining class (__class__in plain Python) and for functions of a module, this is the defining module. In general, it can be any Python object. If__parent__is a class, it carries special semantics: in that case, the function must be called withselfbeing an instance of that class. Finally,__qualname__and__reduce__will use__parent__ as namespace (instead of__self__before).
3. A new attribute__objclass__which equals__parent__if__parent__ is a class. Otherwise, accessing__objclass__raisesAttributeError. This is meant to be backwards compatible withmethod_descriptor.
4. The fieldml_docand the attributes__doc__and __text_signature__(seeArgument Clinic) are not supported.
5. A new flagMETH_PASS_FUNCTIONforml_flags. If this flag is set, the C function stored inml_methis called with an additional first argument equal to the function object.
6. A new flagMETH_BINDINGforml_flagswhich only applies to functions of a module (not methods of a class). If this flag is set, thenm_selfis set toNULLinstead of the module. This allows the function to behave more like a Python function as it enables__get__.
7. A new flagMETH_CALL_UNBOUNDto disableself slicing.
8. A new flagMETH_PYTHONforml_flags. This flag indicates that this function should be treated as Python function. Ideally, use of this flag should be avoided because it goes against the duck typing philosophy. It is still needed in a few places though, for exampleprofiling.

The goal ofbase_functionis that it supports all different ways of calling functions and methods in just one structure. For example, the new flagMETH_PASS_FUNCTION will be used by the implementation of methods.

It is not possible to directly create instances ofbase_function (tp_newisNULL). However, it is legal for C code to manually create instances.

These are the relevant C structures:

PyTypeObjectPyBaseFunction_Type;

typedefstruct{
PyObject_HEAD
PyCFunctionDef*m_ml;/*DescriptionoftheCfunctiontocall*/
PyObject*m_self;/*__self__:anything,canbeNULL;readonly*/
PyObject*m_module;/*__module__:anything(typicallystr)*/
PyObject*m_parent;/*__parent__:anything,canbeNULL;readonly*/
PyObject*m_weakreflist;/*Listofweakreferences*/
}PyBaseFunctionObject;

typedefstruct{
constchar*ml_name;/*Thenameofthebuilt-infunction/method*/
PyCFunctionml_meth;/*TheCfunctionthatimplementsit*/
intml_flags;/*CombinationofMETH_xxxflags,whichmostly
describetheargsexpectedbytheCfunc*/
}PyCFunctionDef;

Subclasses may extendPyCFunctionDefwith extra fields.

The Python attribute__self__returnsm_self, except ifMETH_STATICis set. In that case or ifm_selfisNULL, then there is no__self__attribute at all. For that reason, we write eitherm_selfor__self__in this PEP with slightly different meanings.

cfunction

This is the new version of the oldbuiltin_function_or_methodclass. The namecfunctionwas chosen to avoid confusion with “built-in” in the sense of “something in thebuiltinsmodule”. It also fits better with the C API which use thePyCFunctionprefix.

The classcfunctionis a copy ofbase_function,with the following differences:

1. m_mlpoints to aPyMethodDefstructure, extendingPyCFunctionDefwith an additionalml_doc field to implement__doc__and__text_signature__ as read-only attributes:

   typedefstruct{
   constchar*ml_name;
   PyCFunctionml_meth;
   intml_flags;
   constchar*ml_doc;
   }PyMethodDef;
   

   Note thatPyMethodDefis part of thePython Stable ABI and it is used by practically all extension modules, so we absolutely cannot change this structure.

2. Argument Clinicis supported.
3. __self__always exists. In the cases wherebase_function.__self__ would raiseAttributeError,insteadNoneis returned.

The type object isPyTypeObjectPyCFunction_Type and we definePyCFunctionObjectas alias ofPyBaseFunctionObject (except for the type ofm_ml).

defined_function

The classdefined_functionis an abstract base class meant to indicate that the function has introspection support. Instances ofdefined_functionare required to support all attributes that Python functions have, namely __code__,__globals__,__doc__, __defaults__,__kwdefaults__,__closure__and__annotations__. There is also a__dict__to support attributes added by the user.

None of these is required to be meaningful. In particular,__code__may not be a working code object, possibly only a few fields may be filled in. This PEP does not dictate how the various attributes are implemented. They may be simple struct members or more complicated descriptors. Only read-only support is required, none of the attributes is required to be writable.

The classdefined_functionis mainly meant for auto-generated C code, for example produced by Cython[1]. There is no API to create instances of it.

The C structure is the following:

PyTypeObjectPyDefinedFunction_Type;

typedefstruct{
PyBaseFunctionObjectbase;
PyObject*func_dict;/*__dict__:dictorNULL*/
}PyDefinedFunctionObject;

TODO:maybe find a better name fordefined_function. Other proposals:inspect_function(anything that satisfiesinspect.isfunction), builtout_function(a function that is better built out; pun on builtin), generic_function(original proposal but conflicts withfunctools.singledispatchgeneric functions), user_function(defined by the user as opposed to CPython).

function

This is the class meant for functions implemented in Python. Unlike the other function types, instances offunctioncan be created from Python code. This is not changed, so we do not describe the details in this PEP.

The layout of the C structure is the following:

PyTypeObjectPyFunction_Type;

typedefstruct{
PyBaseFunctionObjectbase;
PyObject*func_dict;/*__dict__:dictorNULL*/
PyObject*func_code;/*__code__:code*/
PyObject*func_globals;/*__globals__:dict;readonly*/
PyObject*func_name;/*__name__:string*/
PyObject*func_qualname;/*__qualname__:string*/
PyObject*func_doc;/*__doc__:canbeanythingorNULL*/
PyObject*func_defaults;/*__defaults__:tupleorNULL*/
PyObject*func_kwdefaults;/*__kwdefaults__:dictorNULL*/
PyObject*func_closure;/*__closure__:tupleofcellobjectsorNULL;readonly*/
PyObject*func_annotations;/*__annotations__:dictorNULL*/
PyCFunctionDef_ml;/*Storageforbase.m_ml*/
}PyFunctionObject;

The descriptor__name__returnsfunc_name. When setting__name__,alsobase.m_ml->ml_nameis updated with the UTF-8 encoded name.

The_mlfield reserves space to be used bybase.m_ml.

Abase_functioninstance must have the flagMETH_PYTHONset if and only if it is an instance offunction.

When constructing an instance offunctionfromcodeandglobals, an instance is created withbase.m_ml=&_ml, base.m_self=NULL.

To make subclassing easier, we also add a copy constructor: iffis an instance offunction,thentypes.FunctionType(f)copiesf. This conveniently allows using a custom function type as decorator:

>>>fromtypesimportFunctionType
>>>classCustomFunction(FunctionType):
...pass
>>>@CustomFunction
...deff(x):
...returnx
>>>type(f)
<class '__main__.CustomFunction'>

This also removes many use cases offunctools.wraps: wrappers can be replaced by subclasses offunction.

bound_method

The classbound_methodis used for all bound methods, regardless of the class of the underlying function. It adds one new attribute on top ofbase_function: __func__points to that function.

bound_methodreplaces the oldmethodclass which was used only for Python functions bound as method.

There is a complication because we want to allow constructing a method from an arbitrary callable. This may be an already-bound method or simply not an instance ofbase_function. Therefore, in practice there are two kinds of methods:

• For arbitrary callables, we use a single fixedPyCFunctionDef structure with theMETH_PASS_FUNCTIONflag set.
• For methods which bind instances ofbase_function (more precisely, which have thePy_TPFLAGS_BASEFUNCTIONflag set) that haveself slicing, we instead use thePyCFunctionDeffrom the original function. This way, we don’t lose any performance when calling bound methods. In this case, the__func__attribute is only used to implement various attributes but not for calling the method.

When constructing a new method from abase_function, we check that theselfobject is an instance of__objclass__ (if a class was specified as parent) and raise aTypeErrorotherwise.

The C structure is:

PyTypeObjectPyMethod_Type;

typedefstruct{
PyBaseFunctionObjectbase;
PyObject*im_func;/*__func__:functionimplementingthemethod;readonly*/
}PyMethodObject;

Checking __objclass__

First of all, a type check is done if the__parent__of the function is a class (recall that__objclass__then becomes an alias of__parent__): ifm_selfisNULL(this is the case for unbound methods of extension types), then the function must be called with at least one positional argument and the first (typically calledself) must be an instance of__objclass__. If not, aTypeErroris raised.

Note that bound methods havem_self!=NULL,so the__objclass__ is not checked. Instead, the__objclass__check is done when constructing the method.

Flags

For convenience, we define a new constant: METH_CALLFLAGScombines all flags fromPyCFunctionDef.ml_flags which specify the signature of the C function to be called. It is equal to

METH_VARARGS|METH_FASTCALL|METH_NOARGS|METH_O|METH_KEYWORDS|METH_PASS_FUNCTION

Exactly one of the first four flags above must be set and onlyMETH_VARARGSandMETH_FASTCALLmay be combined withMETH_KEYWORDS. Violating these rules is undefined behaviour.

There are one new flags which affects calling functions, namelyMETH_PASS_FUNCTIONandMETH_CALL_UNBOUND. Some flags are already documented in[5]. We explain the others below.

Self slicing

If the function hasm_self==NULLand the flagMETH_CALL_UNBOUND is not set, then the first positional argument (if any) is removed from*argsand instead passed as first argument to the C function. Effectively, the first positional argument is treated as__self__. This is meant to support unbound methods such that the C function does not see the difference between bound and unbound method calls. This does not affect keyword arguments in any way.

This process is calledself slicingand a function is said to have self slicingifm_self==NULLandMETH_CALL_UNBOUNDis not set.

Note that aMETH_NOARGSfunction which has self slicing effectively has one argument, namelyself. Analogously, aMETH_Ofunction with self slicing has two arguments.

METH_PASS_FUNCTION

If this flag is set, then the C function is called with an additional first argument, namely the function itself (thebase_functioninstance). As special case, if the function is abound_method, then the underlying function of the method is passed (but not recursively: if abound_methodwraps abound_method, then__func__is only applied once).

For example, an ordinaryMETH_VARARGSfunction has signature (PyObject*self,PyObject*args). WithMETH_VARARGS|METH_PASS_FUNCTION,this becomes (PyObject*func,PyObject*self,PyObject*args).

METH_FASTCALL

This is an existing but undocumented flag. We suggest to officially support and document it.

If the flagMETH_FASTCALLis set withoutMETH_KEYWORDS, then theml_methfield is of typePyCFunctionFast which takes the arguments(PyObject*self,PyObject*const*args,Py_ssize_tnargs). Such a function takes only positional arguments and they are passed as plain C array argsof lengthnargs.

If the flagsMETH_FASTCALL|METH_KEYWORDSare set, then theml_methfield is of typePyCFunctionFastKeywords which takes the arguments(PyObject*self,PyObject*const*args,Py_ssize_tnargs,PyObject*kwnames). The positional arguments are passed as C arrayargsof lengthnargs. Thevaluesof the keyword arguments follow in that array, starting at positionnargs. Thekeys(names) of the keyword arguments are passed as atupleinkwnames. As an example, assume that 3 positional and 2 keyword arguments are given. Thenargsis an array of length 3 + 2 = 5,nargsequals 3 andkwnamesis a 2-tuple.

Unbound methods of extension types

The type of unbound methods changes frommethod_descriptor tocfunction. The object which appears as unbound method is the same object which appears in the class__dict__. Python automatically sets the__parent__attribute to the defining class.

Built-in functions of a module

For the case of functions of a module, __parent__will be set to the module. Unless the flagMETH_BINDINGis given, also__self__ will be set to the module (for backwards compatibility).

An important consequence is that such functions by default do not become methods when used as attribute (base_function.__get__only does that ifm_selfwasNULL). One could consider this a bug, but this was done for backwards compatibility reasons: in an initial post on Python -ideas[6]the consensus was to keep this misfeature of built-in functions.

However, to allow this anyway for specific or newly implemented built-in functions, theMETH_BINDINGflag prevents setting__self__.

New type flag

A newPyTypeObjectflag (fortp_flags) is added: Py_TPFLAGS_BASEFUNCTIONto indicate that instances of this type are functions which can be called and bound as method like abase_function.

This is different from flags likePy_TPFLAGS_LIST_SUBCLASS because it indicates more than just a subclass: it also indicates a default implementation of__call__and__get__. In particular, such subclasses ofbase_function must follow the implementation from the sectionCalling base_function instances.

This flag is automatically set for extension types which inherit thetp_callandtp_descr_getimplementation frombase_function. Extension types can explicitly specify it if they override__call__or__get__in a compatible way. The flagPy_TPFLAGS_BASEFUNCTIONmust never be set for a heap type because that would not be safe (heap types can be changed dynamically).

C API functions

We list some relevant Python/C API macros and functions. Some of these are existing (possibly changed) functions, some are new:

• intPyBaseFunction_CheckFast(PyObject*op):return true ifop is an instance of a class with thePy_TPFLAGS_BASEFUNCTIONset. This is the function that you need to use to determine whether it is meaningful to access thebase_functioninternals.
• intPyBaseFunction_Check(PyObject*op):return true ifop is an instance ofbase_function.
• PyObject*PyBaseFunction_New(PyTypeObject*cls,PyCFunctionDef*ml,PyObject*self,PyObject*module,PyObject*parent): create a new instance ofcls(which must be a subclass ofbase_function) from the given data.
• intPyCFunction_Check(PyObject*op):return true ifop is an instance ofcfunction.
• intPyCFunction_NewEx(PyMethodDef*ml,PyObject*self,PyObject*module): create a new instance ofcfunction. As special case, ifselfisNULL, then setself=Py_Noneinstead (for backwards compatibility). Ifselfis a module, then__parent__is set toself. Otherwise,__parent__isNULL.
• For many existingPyCFunction_...andPyMethod_functions, we define a new functionPyBaseFunction_... acting onbase_functioninstances. The old functions are kept as aliases of the new functions.
• intPyFunction_Check(PyObject*op):return true ifop is an instance ofbase_functionwith theMETH_PYTHONflag set (this is equivalent to checking whetheropis an instance offunction).
• intPyFunction_CheckFast(PyObject*op):equivalent to PyFunction_Check(op)&&PyBaseFunction_CheckFast(op).
• intPyFunction_CheckExact(PyObject*op):return true if the type ofopisfunction.
• PyObject*PyFunction_NewPython(PyTypeObject*cls,PyObject*code,PyObject*globals,PyObject*name,PyObject*qualname): create a new instance ofcls(which must be a subclass offunction) from the given data.
• PyObject*PyFunction_New(PyObject*code,PyObject*globals): create a new instance offunction.
• PyObject*PyFunction_NewWithQualName(PyObject*code,PyObject*globals,PyObject*qualname): create a new instance offunction.
• PyObject*PyFunction_Copy(PyTypeObject*cls,PyObject*func): create a new instance ofcls(which must be a subclass offunction) by copying a givenfunction.

Changes to the types module

Two types are added:types.BaseFunctionTypecorresponding to base_functionandtypes.DefinedFunctionTypecorresponding to defined_function.

Apart from that, no changes to thetypesmodule are made. In particular,types.FunctionTyperefers tofunction. However, the actual types will change: in particular,types.BuiltinFunctionTypewill no longer be the same astypes.BuiltinMethodType.

Changes to the inspect module

The new functioninspect.isbasefunctionchecks for an instance ofbase_function.

inspect.isfunctionchecks for an instance ofdefined_function.

inspect.isbuiltinchecks for an instance ofcfunction.

inspect.isroutinechecksisbasefunctionorismethoddescriptor.

NOTE:bpo-33261[3]should be fixed first.

Profiling

Currently,sys.setprofilesupportsc_call,c_returnandc_exception events for built-in functions. These events are generated when calling or returning from a built-in function. By contrast, thecallandreturnevents are generated by the function itself. So nothing needs to change for thecallandreturnevents.

Since we no longer make a difference between C functions and Python functions, we need to prevent thec_*events for Python functions. This is done by not generating those events if the METH_PYTHONflag inml_flagsis set.

Why not simply change existing classes?

One could try to solve the problem by keeping the existing classes without introducing a newbase_functionclass.

That might look like a simpler solution but it is not: it would require introspection support for 3 distinct classes: function,builtin_function_or_methodandmethod_descriptor. For the latter two classes, “introspection support” would mean at a minimum allowing subclassing. But we don’t want to lose performance, so we want fast subclass checks. This would require two new flags intp_flags. And we want subclasses to allow__get__for built-in functions, so we should implement theLOAD_METHODopcode for built-in functions too. More generally, a lot of functionality would need to be duplicated and the end result would be far more complex code.

It is also not clear how the introspection of built-in function subclasses would interact with__text_signature__. Having two independent kinds ofinspect.signaturesupport on the same class sounds like asking for problems.

And this would not fix some of the other differences between built-in functions and Python functions that were mentioned in themotivation.

Why __text_signature__ is not a solution

Built-in functions have an attribute__text_signature__, which gives the signature of the function as plain text. The default values are evaluated byast.literal_eval. Because of this, it supports only a small number of standard Python classes and not arbitrary Python objects.

And even if__text_signature__would allow arbitrary signatures somehow, that is only one piece of introspection: it does not help withinspect.getsourcefilefor example.

defined_function versus function

In many places, a decision needs to be made whether the oldfunctionclass should be replaced bydefined_functionor the newfunctionclass. This is done by thinking of the most likely use case:

1. types.FunctionTyperefers tofunctionbecause that type might be used to construct instances usingtypes.FunctionType(...).
2. inspect.isfunction()refers todefined_function because this is the class where introspection is supported.
3. The C API functions must refer tofunctionbecause we do not specify how the various attributes ofdefined_function are implemented. We expect that this is not a problem since there is typically no reason for introspection to be done by C extensions.

Scope of this PEP: which classes are involved?

The main motivation of this PEP is fi xing function classes, so we certainly want to unify the existing classes builtin_function_or_methodandfunction.

Since built-in functions and methods have the same class, it seems natural to include bound methods too. And since there are no “unbound methods” for Python functions, it makes sense to get rid of unbound methods for extension types.

For now, no changes are made to the classesstaticmethod, classmethodandclassmethod_descriptor. It would certainly make sense to put these in thebase_function class hierarchy and unifyclassmethodandclassmethod_descriptor. However, this PEP is already big enough and this is left as a possible future improvement.

Slot wrappers for extension types like__init__or__eq__ are quite different from normal methods. They are also typically not called directly because you would normally writefoo[i]instead offoo.__getitem__(i). So these are left outside the scope of this PEP.

Python also has aninstancemethodclass, which seems to be a relic from Python 2, where it was used for bound and unbound methods. It is not clear whether there is still a use case for it. In any case, there is no reason to deal with it in this PEP.

TODO:shouldinstancemethodbe deprecated? It doesn’t seem used at all within CPython 3.7, but maybe external packages use it?

Not treating METH_STATIC and METH_CLASS

Almost nothing in this PEP refers to the flagsMETH_STATICandMETH_CLASS. These flags are checked only by theautomatic creation of built-in functions. When astaticmethod,classmethodorclassmethod_descriptor is bound (i.e.__get__is called), abase_functioninstance is created withm_self!=NULL. For aclassmethod,this is obvious sincem_self is the class that the method is bound to. For astaticmethod,one can take an arbitrary Python object form_self. For backwards compatibility, we choosem_self=__parent__for static methods of extension types.

__self__ in base_function

It may look strange at first sight to add the__self__slot inbase_functionas opposed tobound_method. We took this idea from the existingbuiltin_function_or_methodclass. It allows us to have a single general implementation of__call__and__get__ for the various function classes discussed in this PEP.

It also makes it easy to support existing built-in functions which set__self__to the module (for example,sys.exit.__self__issys).

Two implementations of __doc__

base_functiondoes not support function docstrings. Instead, the classescfunctionandfunction each have their own way of dealing with docstrings (andbound_methodjust takes the__doc__from the wrapped function).

Forcfunction,the docstring is stored (together with the text signature) as C string in the read-onlyml_docfield of aPyMethodDef. Forfunction,the docstring is stored as a writable Python object and it does not actually need to be a string. It looks hard to unify these two very different ways of dealing with__doc__. For backwards compatibility, we keep the existing implementations.

Fordefined_function,we require__doc__to be implemented but we do not specify how. A subclass can implement__doc__the same way ascfunctionor using a struct member or some other way.

Subclassing

We disallow subclassing ofcfunctionandbound_method to enable fast type checks forPyCFunction_CheckandPyMethod_Check.

We allow subclassing of the other classes because there is no reason to disallow it. For Python modules, the only relevant class to subclass is functionbecause the others cannot be instantiated anyway.

Replacing tp_call: METH_PASS_FUNCTION and METH_CALL_UNBOUND

The new flagsMETH_PASS_FUNCTIONandMETH_CALL_UNBOUND are meant to support cases where formerly a customtp_callwas used. It reduces the number of special fast paths inPython/ceval.c for calling objects: instead of treating Python functions, built-in functions and method descriptors separately, there would only be a single check.

The signature oftp_callis essentially the signature ofPyBaseFunctionObject.m_ml.ml_methwith flags METH_VARARGS|METH_KEYWORDS|METH_PASS_FUNCTION|METH_CALL_UNBOUND (the only difference is an addedselfargument). Therefore, it should be easy to change existingtp_callslots to use thebase_functionimplementation instead.

It also makes sense to useMETH_PASS_FUNCTIONwithoutMETH_CALL_UNBOUND in cases where the C function simply needs access to additional metadata from the function, such as the__parent__. This is for example needed to supportPEP 573. Converting existing methods to useMETH_PASS_FUNCTIONis trivial: it only requires adding an extra argument to the C function.

Changes to types and inspect

The proposed changes totypesandinspect are meant to minimize changes in behaviour. However, it is unavoidable that some things change and this can cause code which usestypesorinspectto break. In the Python standard library for example, changes are needed in thedoctestmodule because of this.

Also, tools which take various kinds of functions as input will need to deal with the new function hierarchy and the possibility of custom function classes.

Python functions

For Python functions, essentially nothing changes. The attributes that existed before still exist and Python functions can be initialized, called and turned into methods as before.

The namefunctionis kept for backwards compatibility. While it might make sense to change the name to something more specific likePython _function, that would require a lot of annoying changes in documentation and testsuites.

Built-in functions of a module

Also for built-in functions, nothing changes. We keep the old behaviour that such functions do not bind as methods. This is a consequence of the fact that__self__is set to the module.

Built-in bound and unbound methods

The types of built-in bound and unbound methods will change. However, this does not affect calling such methods because the protocol inbase_function.__call__ (in particular the handling of__objclass__and self slicing) was specifically designed to be backwards compatible. All attributes which existed before (like__objclass__and__self__) still exist.

New attributes

Some objects get new special double-underscore attributes. For example, the new attribute__parent__appears on all built-in functions and all methods get a__func__attribute. The fact that__self__is now a special read-only attribute for Python functions caused trouble in[4]. Generally, we expect that not much will break though.

method_descriptor and PyDescr_NewMethod

The classmethod_descriptorand the constructorPyDescr_NewMethod should be deprecated. They are no longer used by CPython itself but are still supported.

Phase one: keep existing classes but add base classes

Initially, implement thebase_functionclass and use it as common base class but otherwise keep the existing classes (but not their implementation).

In this proposal, the class hierarchy would become:

object
|
|
base_function
/|\
/|\
/|\
cfunction|defined_function
|||\
||bound_method\
||\
|method_descriptorfunction
|
builtin_function_or_method

The leaf classesbuiltin_function_or_method,method_descriptor, bound_methodandfunctioncorrespond to the existing classes (withmethodrenamed tobound_method).

Automatically created functions created in modules become instances ofbuiltin_function_or_method. Unbound methods of extension types become instances ofmethod_descriptor.

The classmethod_descriptoris a copy ofcfunctionexcept that__get__returns abuiltin_function_or_methodinstead of a bound_method.

The classbuiltin_function_or_methodhas the same C structure as a bound_method,but it inherits fromcfunction. The__func__attribute is not mandatory: it is only defined when binding amethod_descriptor.

We keep the implementation of theinspectfunctions as they are. Because of this and because the existing classes are kept, backwards compatibility is ensured for code doing type checks.

Since showing an actualDeprecationWarningwould affect a lot of correctly-functioning code, any deprecations would only appear in the documentation. Another reason is that it is hard to show warnings for callingisinstance(x,t) (but it could be done using__instancecheck__hacking) and impossible fortype(x)ist.

Phase two

Phase two is what is actually described in the rest of this PEP. In terms of implementation, it would be a relatively small change compared to phase one.

builtin_function_or_method: built-in functions and bound methods

These are of typePyCFunction_Type with structurePyCFunctionObject:

typedefstruct{
PyObject_HEAD
PyMethodDef*m_ml;/*DescriptionoftheCfunctiontocall*/
PyObject*m_self;/*Passedas'self'argtotheCfunc,canbeNULL*/
PyObject*m_module;/*The__module__attribute,canbeanything*/
PyObject*m_weakreflist;/*Listofweakreferences*/
}PyCFunctionObject;

structPyMethodDef{
constchar*ml_name;/*Thenameofthebuilt-infunction/method*/
PyCFunctionml_meth;/*TheCfunctionthatimplementsit*/
intml_flags;/*CombinationofMETH_xxxflags,whichmostly
describetheargsexpectedbytheCfunc*/
constchar*ml_doc;/*The__doc__attribute,orNULL*/
};

wherePyCFunctionis a C function pointer (there are various forms of this, the most basic takes two arguments forselfand*args).

This class is used both for functions and bound methods: for a method, them_selfslot points to the object:

>>>dict(foo=42).get
<built-in method get of dict object at 0x...>
>>>dict(foo=42).get.__self__
{'foo': 42}

In some cases, a function is considered a “method” of the module defining it:

>>>importos
>>>os.kill
<built-in function kill>
>>>os.kill.__self__
<module 'posix' (built-in)>

method_descriptor: built-in unbound methods

These are of typePyMethodDescr_Type with structurePyMethodDescrObject:

typedefstruct{
PyDescrObjectd_common;
PyMethodDef*d_method;
}PyMethodDescrObject;

typedefstruct{
PyObject_HEAD
PyTypeObject*d_type;
PyObject*d_name;
PyObject*d_qualname;
}PyDescrObject;

function: Python functions

These are of typePyFunction_Type with structurePyFunctionObject:

typedefstruct{
PyObject_HEAD
PyObject*func_code;/*Acodeobject,the__code__attribute*/
PyObject*func_globals;/*Adictionary(othermappingswon't do) */
PyObject*func_defaults;/*NULLoratuple*/
PyObject*func_kwdefaults;/*NULLoradict*/
PyObject*func_closure;/*NULLoratupleofcellobjects*/
PyObject*func_doc;/*The__doc__attribute,canbeanything*/
PyObject*func_name;/*The__name__attribute,astringobject*/
PyObject*func_dict;/*The__dict__attribute,adictorNULL*/
PyObject*func_weakreflist;/*Listofweakreferences*/
PyObject*func_module;/*The__module__attribute,canbeanything*/
PyObject*func_annotations;/*Annotations,adictorNULL*/
PyObject*func_qualname;/*Thequalifiedname*/

/*Invariant:
*func_closurecontainsthebindingsforfunc_code->co_freevars,so
*PyTuple_Size(func_closure)==PyCode_GetNumFree(func_code)
*(func_closuremaybeNULLifPyCode_GetNumFree(func_code)==0).
*/
}PyFunctionObject;

In Python 3, there is no “unbound method” class: an unbound method is just a plain function.

method: Python bound methods

These are of typePyMethod_Type with structurePyMethodObject:

typedefstruct{
PyObject_HEAD
PyObject*im_func;/*Thecallableobjectimplementingthemethod*/
PyObject*im_self;/*Theinstanceitisboundto*/
PyObject*im_weakreflist;/*Listofweakreferences*/
}PyMethodObject;