[Python-Dev] PEP 575: Unifying function/method classes (original) (raw)
Jeroen Demeyer J.Demeyer at UGent.be
Sun Apr 15 08:50:14 EDT 2018
- Previous message (by thread): [Python-Dev] PEP 575: Unifying function/method classes
- Next message (by thread): [Python-Dev] PEP 575: Unifying function/method classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
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.
Finally: changing the classes of certain objects is exactly the point of this PEP, so it's impossible to achieve 100% backwards compatibility.
Jeroen.
- Previous message (by thread): [Python-Dev] PEP 575: Unifying function/method classes
- Next message (by thread): [Python-Dev] PEP 575: Unifying function/method classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]