A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2018-April/152709.html below:

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

[Python-Dev] PEP 575: Unifying function/method classes [Python-Dev] PEP 575: Unifying function/method classesSerhiy Storchaka storchaka at gmail.com
Sun Apr 15 09:49:26 EDT 2018
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.

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4