[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Serhiy Storchaka added the comment: New changeset 13da1a60f13e173f65bb0da5ab325641d5bb99ec by Serhiy Storchaka (Oren Milman) in branch '2.7': [2.7] bpo-31478: Prevent unwanted behavior in _random.Random.seed() in case the arg has a bad __abs__() method (GH-3596)

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Change by Oren Milman : -- pull_requests: +3826 ___ Python tracker ___ ___

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Serhiy Storchaka added the comment: I agree that a backport is still desirable. Your plan LGTM. Implement __abs__ raising an exception (test both int ant long subclasses). Make sure that no error is raised. Make sure that random() returns the same value as when

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Oren Milman added the comment: With regard to backporting to 2.7: In 2.7 also, PyNumber_Absolute() is called, and its return value is stored in the variable n. However, there is no _PyLong_NumBits(n), so there is no assertion failure. If n isn't an integer: - if

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Serhiy Storchaka added the comment: New changeset befc956acf8ddeb94f000ed081ddec51315429e5 by Serhiy Storchaka in branch '3.6': [3.6] bpo-31478: Fix an assertion failure in random.seed() in case a seed has a bad __abs__() method. (GH-3596) (#3794)

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Change by Serhiy Storchaka : -- pull_requests: +3778 ___ Python tracker ___ ___

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Serhiy Storchaka added the comment: New changeset d780b2d588e68bd7047ef5d1f04e36da38b7a350 by Serhiy Storchaka (Oren Milman) in branch 'master': bpo-31478: Fix an assertion failure in random.seed() in case a seed has a bad __abs__() method. (#3596)

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Raymond Hettinger added the comment: > I don't see reasons why it should obey overriding the __abs__() method. I concur. -- ___ Python tracker ___

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Serhiy Storchaka added the comment: The more I think about this the more I like the idea of using int.__abs__() directly (PyLong_Type.tp_as_number->nb_absolute() in C). The C code doesn't call potentially overridable methods bit_length() and to_bytes(), it uses concrete implementations

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Vedran Čačić added the comment: So floats (and complexes) cannot be seeds anymore? :-o Or this pertains only to ints? In this case, I think the easiest doc fix is to change If a is an int, it is used directly. to If a is an int, its absolute value is used. -- nosy: +veky

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Oren Milman added the comment: i opened a PR that implements the first option, but of course I wouldn't mind if you decide another option is better. -- ___ Python tracker

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Changes by Oren Milman : -- keywords: +patch pull_requests: +3587 stage: -> patch review ___ Python tracker ___

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Serhiy Storchaka added the comment: There are several ways of solving this issue: 1. Verify that an actual int was returned and raise a TypeError if it wasn't. 2. Verify that an actual int was returned and fall back to the hash if it wasn't. 3. Use int.__abs__() instead of abs(), the result

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Oren Milman added the comment: sure. but what about the TypeError message? should it complain about the return value of abs(seed)? (the docs of random.seed don't mention abs().) -- ___ Python tracker

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Raymond Hettinger added the comment: It would make sense to verify that an actual int was returned and to raise a TypeError if it wasn't. Do you want to submit a PR (with a test case)? -- nosy: +rhettinger, serhiy.storchaka ___ Python tracker

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

New submission from Oren Milman: The following code causes an assertion failure: class BadInt(int): def __abs__(self): return None import random random.seed(BadInt()) this is because random_seed() (in Modules/_randommodule.c) assumes that PyNumber_Absolute() returned an int, and