[Python-Dev] PEP 575: Unifying function/method classes
Serhiy Storchaka
storchaka at gmail.com
Sun Apr 15 09:49:26 EDT 2018
More information about the Python-Dev mailing list
Sun Apr 15 09:49:26 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 ]
15.04.18 16:09, Nick Coghlan пише: > On 15 April 2018 at 22:50, Jeroen Demeyer <J.Demeyer at 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). See https://bugs.python.org/issue33144.
- 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 ]
More information about the Python-Dev mailing list