[Python-Dev] PEP 575: Unifying function/method classes (original) (raw)

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