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.
On 15 April 2018 at 22:50, Jeroen Demeyer J.Demeyer@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@gmail.com | Brisbane, Australia
15.04.18 16:09, Nick Coghlan пише:
On 15 April 2018 at 22:50, Jeroen Demeyer J.Demeyer@ugent.be wrote:
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).
On Apr 15, 2018, at 5:50 AM, Jeroen Demeyer J.Demeyer@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
-
Jeroen Demeyer -
Nick Coghlan -
Raymond Hettinger -
Serhiy Storchaka