I used astsearch to search all combinations and also only found four (which
were not sliced, just indexed)

sympymaster%=$astsearch 'range(?)[?]' sympy/
sympy/matrices/dense.py
  77|                    i = range(self.rows)[i]
  83|                    j = range(self.cols)[j]

sympy/matrices/sparse.py
  99|                    i = range(self.rows)[i]
 107|                    j = range(self.cols)[j]
sympymaster%=$astsearch 'range(?)[?:?]' sympy/
sympymaster%=$astsearch 'range(?)[?:?:?]' sympy/
sympymaster%=$astsearch 'range(?)[?::?]' sympy/
sympymaster%=$astsearch 'range(?)[:?:?]' sympy/
sympymaster%=$astsearch 'range(?)[?:?:]' sympy/
sympymaster%=$astsearch 'range(?)[?:]' sympy/
sympymaster%=$astsearch 'range(?)[:?]' sympy/
sympymaster%=$astsearch 'range(?)[:]' sympy/
sympymaster%=$astsearch 'range(?)[::]' sympy/
sympymaster%=$astsearch 'range(?)[?::]' sympy/
sympymaster%=$astsearch 'range(?)[:?:]' sympy/
sympymaster%=$astsearch 'range(?)[::?]' sympy/

What is the point of "i = range(self.rows)[i]"? That's the same as

if not 0 <= i < self.rows:
    raise IndexError

And there's probably a better way to manage the logic than by using
IndexError anyway.

Aaron Meurer

On Sun, Feb 1, 2015 at 1:17 PM, Chris Smith <[email protected]> wrote:

> 4 places (https://github.com/sympy/sympy/pull/8914) which have been
> marked with a note telling how they should be modified once PY2 is dropped.
>
> On Sunday, February 1, 2015 at 12:57:57 PM UTC-6, Aaron Meurer wrote:
>>
>> I don't think it's necessary to depend on future, although we can
>> certainly borrow code from it. But how many places in the code slice a
>> range (and of them, how many of them have to be xrange in Python 2)?
>>
>> Aaron Meurer
>>
>> On Sat, Jan 31, 2015 at 10:39 PM, Chris Smith <[email protected]> wrote:
>>
>>> I was talking with @asmeurer and @jayesh92 this afternoon about removing
>>> xrange from the SymPy codebase. There's an interesting dilemma that arises:
>>> there is nothing in PY2 that will emulate the new range in PY3. The most
>>> crippling example is that while range in PY3 can accept a slice like
>>> range(10)[::2], xrange cannot. So in a file where one needs to use an
>>> xrange-like range, it can be imported from compatibility as range (and
>>> compatibility supplies the xrange function which will no longer be
>>> necessary once PY2 is dropped). *But if, in the same file, one slices a
>>> range an error will be raised because the imported xrange (under the alias
>>> range) cannot be sliced that way:
>>>
>>> from sympy.core.compatibility import range
>>> range(10**8)  # ok. We imported range which is really xrange so this
>>> works
>>> ...
>>> range(10)[::2] --> error since xrange cannot be sliced this way
>>>
>>> We can write list(range(10))[::2] to work around the issue but then we
>>> are are forcing people to use PY2 idioms to work around PY2 functions
>>> (xrange) disguised as PY3 functions (range). That's about as bad as
>>> allowing users to use PY2 keywords (like xrange) in a codebase where we are
>>> trying to keep things compatible with PY3.
>>>
>>> There's some really good news to help in this (and other issues): the
>>> "future" project at
>>> I was talking with @asmeurer and @jayesh92 this afternoon about removing
>>> xrange from the SymPy codebase. There's an interesting dilemma that arises:
>>> there is nothing in PY2 that will emulate the new range in PY3. The most
>>> crippling example is that while range in PY3 can accept a slice like
>>> range(10)[::2], xrange cannot. So in a file where one needs to use an
>>> xrange-like range, it can be imported from compatibility as range (and
>>> compatibility supplies the xrange function which will no longer be
>>> necessary once PY2 is dropped). *But if, in the same file, one slices a
>>> range an error will be raised because the imported xrange (under the alias
>>> range) cannot be sliced that way:
>>>
>>> EXAMPLE
>>> ========
>>> from sympy.core.compatibility import range
>>> range(10**8)  # ok. We imported range which is really xrange so this
>>> works
>>> ...
>>> range(10)[::2] --> error since xrange cannot be sliced this way
>>>
>>> We can write list(range(10))[::2] to work around the issue but then we
>>> are are forcing people to use PY2 idioms to work around PY2 functions
>>> (xrange) disguised as PY3 functions (range). That's about as bad as
>>> allowing users to use PY2 keywords (like xrange) in a codebase where we are
>>> trying to keep things compatible with PY3.
>>>
>>> There's some really good news to help in this (and other issues): the
>>> "future" project at http://python-future.org/ . They have already workd
>>> through the issues related to this (and other PY2/3 incompatibilities) so
>>> that in our compatibility file all we would have to do is
>>>
>>> if PY3:
>>>     range = range
>>> else:
>>>     from future.builtins import range
>>>
>>> And then in a file where we want to use xrange we use the compatibility
>>> range instead and now the code in our EXAMPLE above will work -- no
>>> workaround is necessary. That's the way it should be. I would recommend
>>> that as long as we support PY2 we should include `future` like we included
>>> `mpmath` until we drop PY2 support.
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "sympy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/sympy.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/sympy/0e4afab2-6e47-4544-b985-3e670469ff11%40googlegroups.com
>>> <https://groups.google.com/d/msgid/sympy/0e4afab2-6e47-4544-b985-3e670469ff11%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/0a1c98aa-2e7d-4bce-9684-ca8edde6fb91%40googlegroups.com
> <https://groups.google.com/d/msgid/sympy/0a1c98aa-2e7d-4bce-9684-ca8edde6fb91%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BLpf8-SEXAhTWCWcNVauid5ymx3uQO0OEKeAM60TDoJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to