[issue37319] Deprecate using random.randrange() with non-integers

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

[issue37319] Deprecate using random.randrange() with non-integers

2021-01-25 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: New changeset f066bd94b9225a5a3c4ade5fc3ff81e3c49b7b32 by Serhiy Storchaka in branch 'master': bpo-37319: Improve documentation, code and tests of randrange. (GH-19112) https://github.com/python/cpython/commit/f066bd94b9225a5a3c4ade5fc3ff81e3c49b7b32

[issue37319] Deprecate using random.randrange() with non-integers

2020-12-28 Thread Raymond Hettinger
Raymond Hettinger added the comment: I merged in PR 23064. If you want to make further modifications or improvements that would be welcome. -- ___ Python tracker ___

[issue37319] Deprecate using random.randrange() with non-integers

2020-10-31 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: See issue4. As a side effect this change provides 10% speed up (which can be lager after the end of the deprecation period). -- ___ Python tracker

[issue37319] Deprecate using random.randrange() with non-integers

2020-10-31 Thread Serhiy Storchaka
Change by Serhiy Storchaka : -- resolution: rejected -> stage: resolved -> patch review status: closed -> open versions: +Python 3.10 -Python 3.9 ___ Python tracker ___

[issue37319] Deprecate using random.randrange() with non-integers

2020-03-23 Thread Raymond Hettinger
Raymond Hettinger added the comment: Marking this as rejected. Nothing good would come from obfuscating the docs to note a minor implementation detail. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python

[issue37319] Deprecate using random.randrange() with non-integers

2020-03-23 Thread Tim Peters
Tim Peters added the comment: It's neither "bug" nor "feature" - it's an inherited quirk CPython maintains to avoid annoying users for no good reason. If you absolutely have to "do something", how about adding a mere footnote? The docs already imply the args have the same restrictions as

[issue37319] Deprecate using random.randrange() with non-integers

2020-03-23 Thread Raymond Hettinger
Raymond Hettinger added the comment: How about we just leave it alone. AFAICT nothing is broken -- no user is having any issues. We really don't need to go through every tool in the standard library that uses int() and document that it accepts any type that defines __int__, nor do we need

[issue37319] Deprecate using random.randrange() with non-integers

2020-03-23 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: If you are against deprecating this "feature", it should be at least documented and covered by tests. -- ___ Python tracker ___

[issue37319] Deprecate using random.randrange() with non-integers

2020-03-22 Thread Tim Peters
Tim Peters added the comment: I have scant memory of working on this code. But back then Python wasn't at all keen to enforce type checking in harmless contexts. If, e.g., someone found it convenient to pass integers that happened to be in float format to randrange(), why not? Going

[issue37319] Deprecate using random.randrange() with non-integers

2020-03-22 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Using index() simplifies the code. Adding deprecation warnings complicates it. The PR consists of two commits, look at the first one to see how the code can finally look. If you think that the deprecation is not needed, we can just keep the simplified

[issue37319] Deprecate using random.randrange() with non-integers

2020-03-22 Thread Raymond Hettinger
Raymond Hettinger added the comment: I'm generally against "fixing" things that aren't broken. AFAICT, this has never been an issue for any real user over its 20 year history. Also, the current PR makes the code look gross and may impact code that is currently working. Tim, this is

[issue37319] Deprecate using random.randrange() with non-integers

2020-03-22 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Many functions that accepts non-integer arguments (except float) and truncate them to integers emits a deprecation warning since 3.8 (see issue36048 and issue20092). They will be errors in 3.10 (see 37999). --

[issue37319] Deprecate using random.randrange() with non-integers

2020-03-22 Thread Serhiy Storchaka
Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +18473 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19112 ___ Python tracker

[issue37319] Deprecate using random.randrange() with non-integers

2019-06-20 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Why this code uses int() at all? My guess is that it was added for earlier detection of user errors, otherwise the user could get a TypeError or AttributeError with unrelated message, or even a wrong result. int() is used just for type checking. But it is

[issue37319] Deprecate using random.randrange() with non-integers

2019-06-17 Thread Raymond Hettinger
Raymond Hettinger added the comment: We probably should not do this until we're willing to give PEP 8 guidance recommending operator.index() as preferable to int() for all cases needing integer offsets. Maybe we do want to go down that path or maybe we just stick with "practicality beats

[issue37319] Deprecate using random.randrange() with non-integers

2019-06-17 Thread Raymond Hettinger
Raymond Hettinger added the comment: While there isn't anything intrinsically wrong with using index(), the premise of this issue is essentially a claim that most Python code that uses int() is wrong. That seems rather bold and flies in the face of common practices. I don't really like

[issue37319] Deprecate using random.randrange() with non-integers

2019-06-17 Thread Serhiy Storchaka
New submission from Serhiy Storchaka : Unlike other range()-like functions random.randrange() accepts not only integers and integer-like objects (implementing __index__), but any numbers with integral values, like 3.0 or Decimal(3). In 3.8 using __int__ for implicit converting to C integers