You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm doing a conversion here locally and I've just been debugging an error that was introduced after running modernize over some code. I've caught it and can fix this a couple ways however, should modernize be converting range like this?
Here's the stripped back example with static indexes and suchlike:
for x in range(10)[5:]: # skip first values
print x
after modernize
from __future__ import print_function
from six.moves import range
for x in range(10)[5:]: # skip first values
print(x)
The problem here is that range from six.moves is xrange which doesn't support slice notation. Running the new code (at least in my 2.7.3 environment) results in the following traceback:
Traceback (most recent call last):
File "file.py", line 3, in <module>
for x in range(10)[5:]: # skip first values
TypeError: sequence index must be integer, not 'slice'
I can locally trap this with tests, but this seems like a case where the range -> six.moves.range call almost would need to be wrapped with a list for py2 purposes? list(range (10))[5:] would've been fine.
If this behaviour isn't expected, I can try draft up a patch - it's not a major challenge in the code I'm looking at (it's a 'nice' hard fail if there's a test suite covering the code path) but this feels slightly strange to convert range from a list to an xrange generator
The text was updated successfully, but these errors were encountered:
I'm doing a conversion here locally and I've just been debugging an error that was introduced after running
modernize
over some code. I've caught it and can fix this a couple ways however, shouldmodernize
be converting range like this?Here's the stripped back example with static indexes and suchlike:
after modernize
The problem here is that range from
six.moves
isxrange
which doesn't support slice notation. Running the new code (at least in my 2.7.3 environment) results in the following traceback:I can locally trap this with tests, but this seems like a case where the range -> six.moves.range call almost would need to be wrapped with a list for py2 purposes?
list(range (10))[5:]
would've been fine.If this behaviour isn't expected, I can try draft up a patch - it's not a major challenge in the code I'm looking at (it's a 'nice' hard fail if there's a test suite covering the code path) but this feels slightly strange to convert range from a list to an xrange generator
The text was updated successfully, but these errors were encountered: