feat(arithmetic): 🪜 floordiv

[cmp0xff]

This PR adds floordiv for Index and Series.

• Addresses Index arithmetic overloads show wrong types #1347 and Create tests for arithmetic for TimedeltaIndex and DatetimeIndex #1378
• Tests added

[Dr-Irv]

A few things:

1. You're inconsistent when having timedelta divided by int where "divided" is either regular division or floor division, and timedelta is a single element or a sequence of some type. You have that as being not allowed in the stubs, but they work at runtime. Sometimes you do allow it, so you have to fix that.
2. There are a few places where you say you can't detect via static typing, and I'm surprised at that.

Also, you are making changes here that are independent of supporting floordiv, namely:

1. You changed the pyrefly override syntax
2. You changed some imports from from pandas import Series to from pandas.core.series import Series

In the future, if you are making changes where the changes don't have to do with the main intent of the PR, make a separate PR for those changes. E.g., in the above case, you could do one for pyrefly and another to change the imports.

[cmp0xff]

1. You're inconsistent when having `timedelta` divided by `int` where "divided" is either regular division or floor division, and `timedelta` is a single element or a sequence of some type.  You have that as being not allowed in the stubs, but they work at runtime.  Sometimes you do allow it, so you have to fix that.

When the runtime result has the correct dtype, this PR should give type hints. When the operation crashes at runtime or gives object as dtype, this PR should show error. This was discussed in e.g. #1431 (comment), where Index[Timedelta] (which has dtype object) is banned.

2. There are a few places where you say you can't detect via static typing, and I'm surprised at that.

Still working on them. Will ping when finished.

1. You changed the `pyrefly` override syntax

Will do separately

2. You changed some imports from `from pandas import Series` to `from pandas.core.series import Series`

Will do separately.

[Dr-Irv]

When the runtime result has the correct dtype, this PR should give type hints. When the operation crashes at runtime or gives object as dtype, this PR should show error. This was discussed in e.g. #1431 (comment), where Index[Timedelta] (which has dtype object) is banned.

I think this situation is different. When we banned Index[Timedelta] when the dtype was object, my concern was that you were doing tests using that type, and we don't want to assume it could be created.

Here, this is about the results of the computation. If we know the result has object dtype, I think the stubs can return a result without a specified value of S1 (i.e., either Index or Index[Any]; Series or Series[Any])

[Dr-Irv]

pretty close. Only a few things left

[Dr-Irv]

surprised that pyright isn't detecting this one

[cmp0xff]

I don't have further insights 😔

[Dr-Irv]

It's on the numpy side. pyright sees the type of s as "ndarray[tuple[Any, ...], dtype[datetime64[date | int | None]]]" . numpy has this overload that matches:

    @overload
    def __truediv__(self: NDArray[Any], other: _ArrayLikeObject_co, /) -> Any: ...

Can you add a comment that indicates that numpy is not picking up that dividing a numpy array by anything and link to this issue I just created? numpy/numpy#30173

[cmp0xff]

b85a68a

[Dr-Irv]

One open conversation - just add a comment about why pyright isn't picking up that one case.

[Dr-Irv]

thanks @cmp0xff