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

[Raymond Hettinger]

> On Apr 15, 2018, at 5:50 AM, 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.

Don't worry about Random._randbelow, we're already working on it and it is an easy fix.  Instead, focus on Guido's comment. 

> The fact that there is so little breakage in the standard library makes 
> me confident that the problem is not so bad. And in the cases where it 
> does break, it's usually pretty easy to fix.

I don't think that confidence is warranted.  The world of Python is very large.  When public APIs (such as that in the venerable types module) get changed, is virtually assured that some code will break.


Raymond