Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom None for Slice args? #50

Open
asmeurer opened this issue Jun 22, 2020 · 1 comment
Open

Custom None for Slice args? #50

asmeurer opened this issue Jun 22, 2020 · 1 comment

Comments

@asmeurer
Copy link
Member

A big issue with Slice is that any of the three arguments can be None. So any code that does a numeric check like s.stop < 0 must first check if it is None or it will get a TypeError. In some cases this can be avoided by calling reduce() first, but it can't be avoided in general, since reduce() without a shape cannot remove None from start and stop in all cases.

Instead of requiring all code that deals with Slice to be defensive, I wonder if it would be prudent to have a custom none type that is used in Slice args that has

class none:
    def __lt__(self, other):
        return False
    def __gt__(self, other):
        return False
    def __le__(self, other):
        return False
    def __ge__(self, other):
        return False
    def __eq__(self, other):
        return other == None or isinstance(other, None)

With this, if s.stop < 0 will do the right thing without having to have a guard like if s.stop is not None and s.stop >= 0, and prevents the temptation to write incorrect logic like if s.stop and s.stop >= 0.

The downside is that this will break code that does do is None, and there would be no way to avoid it since it's impossible to override is (we have the same problem with ellipsis(), basically is is terrible).

So I'm not sure if it's a good idea or not. For ndindex library code we can get away with requiring defensive coding because it is so thoroughly tested that any mistake would be caught. But this is also an issue for end-user code as well.

@telamonian
Copy link
Contributor

I'm of the opinion that breaking the basic assumptions of vanilla Python, like how None is supposed to behave, is more likely to cause problems than to solve them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants