Issue 28376: rangeiter_new fails when creating a range of step 0

------------ current state ------------
An assertion in Objects/rangeobject.c might fail:
    >>> type(iter(range(0)))
    <class 'range_iterator'>
    >>> type(iter(range(0)))(1, 1, 0)
    Assertion failed: step != 0, file ..\Objects\rangeobject.c, line 895

This is caused by the lack of a check whether 'step' is zero, during the creation of a range_iterator object, in rangeiter_new.

Note that during the creation of a range object, the function range_new does check that, by calling validate_step, which leads to the following behavior:
    >>> range(1, 1, 0)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: range() arg 3 must not be zero
    >>>


------------ proposed changes ------------
    1. In Objects/rangeobject.c in rangeiter_new:
        - in case 'step' is zero, raise a ValueError
        - in error messages, replace 'rangeiter' with 'range_iterator', as the latter is the name of the type in Python code

    2. In Lib/test/test_range.py, add tests for calling the range_iterator type (i.e. creating a range_iterator object)


------------ diff ------------
The proposed patches diff file is attached.


------------ tests ------------
I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output. (That also means my new tests in test_range passed.)
The outputs of both runs are attached.

I'm not able to trigger an assertion error when running the latest trunk in debug mode. I get a "valid" range_iterator object though, and using __reduce__ gives me direct access to `range(0, 0, 0)` (which is completely worthless).

Error or not, this should be fixed, and your patch LGTM. Thanks!

(I changed the type to 'behaviour' since I can't reproduce the assertion, but it doesn't make much of a difference)

patch is LGTM.

But there is one hidden inconsistency:

>>> r = range(2**100)
>>> type(iter(r))
<class 'longrange_iterator'>
>>> type(iter(r))(1, 1, 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'longrange_iterator' instances

Should we have same tp_new method for longrange_iterator?

Good point Naoki. I think we can remove tp_new method from range_iterator in 3.7. Seems it is never used.

The patch LGTM for 3.5-3.6, but the test should be marked as CPython implementation detail (@support.cpython_only).

The diff files for 3.5 and 3.6 are attached (I only added @test.support.cpython_only, as you suggested).

The diff file for 3.7 is also attached. It contains:
    - removing rangeiter_new
    - tests to verify one cannot create instances of range_iterator or longrange_iterator (in CPython)
    - added 'Iterator.register(longrange_iterator)' in Lib/_collections_abc.py

The output of 'python_d.exe -m test -j3' for each version is also attached (they were all successful).

P.S. If we remove the ability to create instances of range_iterator in 3.7, shouldn't we raise a DeprecationWarning in rangeiter_new in 3.5 and 3.6?

Raising a DeprecationWarning in 3.6 doesn't hurt.

rangeiter_new() was added in r55167.

And merged in a6eb6acfe04a.

The diff files for 3.6 and 3.7 are attached (named '*ver3.diff').
Changes:
    - in 3.6, added:
        * raising a DeprecationWarning in rangeiter_new
        * a test to verify the DeprecationWarning is raised
    - in 3.7:
        * changed the tests so they would only verify a TypeError is raised when calling either range_iterator or longrange_iterator
        * removed the test.support.cpython_only decorator of the test

The output of 'python_d.exe -m test -j3' for each version is also attached (they were both successful).

Thanks Oren. Patches for 3.5 and 3.7 LGTM, the patch for 3.6 should be fixed. Tests should pass with -Wa and -We.

No need to attach test output. Just check that your patch doesn't add a regression.

Alright, just added 'with test.support.check_warnings(('', DeprecationWarning)):'.
*ver4.diff is attached.
I ran the tests again (this time using 'python_d.exe -We -m test -j3'), and they were successful :)

That was totally my bad, of course, but anyway, ISTM that https://docs.python.org/devguide/index.html should say './python -We -m test -j3' in section 4 (Run the tests).

New changeset ee049edc3fff by Serhiy Storchaka in branch '3.5':
Issue #28376: Fixed typos.
https://hg.python.org/cpython/rev/ee049edc3fff

New changeset e486f3d30e0e by Serhiy Storchaka in branch '3.5':
Issue #28376: The constructor of range_iterator now checks that step is not 0.
https://hg.python.org/cpython/rev/e486f3d30e0e

New changeset 06f065a59751 by Serhiy Storchaka in branch '3.6':
Issue #28376: Creating instances of range_iterator by calling range_iterator
https://hg.python.org/cpython/rev/06f065a59751

New changeset e099583400f3 by Serhiy Storchaka in branch 'default':
Issue #28376: Creating instances of range_iterator by calling range_iterator
https://hg.python.org/cpython/rev/e099583400f3

New changeset ce4af7593e45 by Serhiy Storchaka in branch '3.5':
Issue #28376: The type of long range iterator is now registered as Iterator.
https://hg.python.org/cpython/rev/ce4af7593e45

Thank you for your contribution Oren.

Thanks for the reviews and patience :)

assignee: serhiy.storchaka
resolution: fixed
stage: patch review -> resolved

messages: + msg278313

messages: + msg278307

messages: + msg278232

versions: + Python 3.5, Python 3.6

type: crash -> behavior
stage: patch review