[Python-Dev] PEP 575: Unifying function/method classes

Nick Coghlan ncoghlan at gmail.com
Sun Apr 15 09:09:16 EDT 2018


On 15 April 2018 at 22:50, Jeroen Demeyer <J.Demeyer at ugent.be> wrote:
> On 2018-04-14 23:14, Guido van Rossum wrote:
>>
>> That actually sounds like a pretty big problem. I'm sure there is lots
>> of code that doesn't *just* duck-type nor calls inspect but uses
>> isinstance() to decide how to extract the desired information.
>
> In the CPython standard library, the *only* fixes that are needed because of
> this are in:
>
> - inspect (obviously)
> - doctest (to figure out the __module__ of an arbitrary object)
> - multiprocessing.reduction (something to do with pickling)
> - xml.etree.ElementTree (to determine whether a certain method was
> overridden)
> - GDB support
>
> I've been told that there might also be a problem with Random._randbelow,
> even though it doesn't cause test failures.

>From Raymond's description (and from an initial reading of the code),
the _randbelow case seems like it may be a latent defect anyway, as it
wouldn't detect cases where the replacement implementation came from
an extension module (e.g. if someone used Cython to compile a module
that subclassed Random and overrode either Random.random or
Random.getrandbits). ("Builtin" is unfortunately a bit of a misnomer
in the existing type names, since extension modules also create
instances of those types)

In a post-PEP-575 world, I believe those checks could be replaced with
the more robust "if random.__func__ is __class__.random or
getrandbits.__func__ is not __class__.getrandbits:" (since unbound
methods go away even for builtin functions, it becomes easier to check
method identity against a baseline implementation).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list