CI/TST: fix failing tests in py37_np_dev

[ShaharNaveh]

No description provided.

[WillAyd]

lgtm if green

[WillAyd]

I think would need to back port as well

[ShaharNaveh]

I think would need to back port as well

I think we do, as this error message is an external error message.

[ShaharNaveh]

I think would need to back port as well

I think we do, as this error message is an external error message.

@jorisvandenbossche I am with you on not testing the error messages from external packages, here we got "lucky" (only 5 instances) but could easily be 40+ (and even more) if something else would have changed.

Any idea on how to mark error messages from external packages?

[ShaharNaveh]

I think would need to back port as well

I think we do, as this error message is an external error message.

@jorisvandenbossche I am with you on not testing the error messages from external packages, here we got "lucky" (only 5 instances) but could easily be 40+ (and even more) if something else would have changed.

Any idea on how to mark error messages from external packages?

Posted in the wrong thread 🤦‍♂️

[ShaharNaveh]

gentle ping @WillAyd ; Linux py37_np_dev is green :)

[jbrockmendel]

nitpick: small preference for "( axis 0 with)?" over "( axis 0 with|)"

[jbrockmendel]

(ok for follow-up, since getting the CI working quickly will be nice)

[lumberbot-app]

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout 1.0.x
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 0f04c6af5eea56f69d046eb1603c25f4b8d45919

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #31091: CI/TST: fix failing tests in py37_np_dev'

4. Push to a named branch :

git push YOURFORK 1.0.x:auto-backport-of-pr-31091-on-1.0.x

5. Create a PR against branch 1.0.x, I would have named this PR:

"Backport PR #31091 on branch 1.0.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

[WillAyd]

Looks like need to manually backport @Momisbestfriend mind doing that?

[ShaharNaveh]

Looks like need to manually backport @MomIsBestFriend mind doing that?

@WillAyd sure!

[ShaharNaveh]

I just checked it again, and this is not an external error message.

pandas/pandas/core/indexes/range.py

Line 698 in a72eef5

f"index {key} is out of bounds for axis 0 with size {len(self)}"

And it's located in:

# class RangeIndex(Int64Index):

def __getitem__(self, key):
        """
        Conserve RangeIndex type for scalar and slice keys.
        """
        if isinstance(key, slice):
            new_range = self._range[key]
            return self._simple_new(new_range, name=self.name)
        elif is_integer(key):
            new_key = int(key)
            try:
                return self._range[new_key]
            except IndexError:
                raise IndexError(
                    f"index {key} is out of bounds for axis 0 with size {len(self)}"
                )
        elif is_scalar(key):
            raise IndexError(
                "only integers, slices (`:`), "
                "ellipsis (`...`), numpy.newaxis (`None`) "
                "and integer or boolean "
                "arrays are valid indices"
            )
        # fall back to Int64Index
        return super().__getitem__(key)

I think that a future version of numpy will break pd.RangeIndex.

cc (@WillAyd, @jreback, @jbrockmendel)

[jorisvandenbossche]

this is not an external error message.

That's only for RangeIndex (where we mimic numpy's behaviour and error messages), for all other cases it comes from numpy I think?

I think that a future version of numpy will break pd.RangeIndex.

How do you mean?

[ShaharNaveh]

How do you mean?

@jorisvandenbossche Now that you explained that

That's only for RangeIndex (where we mimic numpy's behaviour and error messages), for all other cases it comes from numpy I think?

I don't think that a future version of numpy will break RangeIndex, I didn't understand what was going on before, but now I do.

Thank you for your explanation :)