On 15 April 2018 at 22:50, Jeroen Demeyer <j.deme...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com