Skip to content

Conversation

@cmp0xff
Copy link
Contributor

@cmp0xff cmp0xff commented Dec 4, 2025

  • There are a few places where we need to add # pyrefly: ignore[bad-param-name-override]
  • Other places can be fixed by correcting non-functional param names
  • In most places we have one space between two ignores on the same line. I have fixed those with two spaces.

def size(self) -> int: ...
@overload
def __getitem__(self, key: ScalarIndexer) -> DTScalarOrNaT: ...
def __getitem__(self, item: ScalarIndexer) -> DTScalarOrNaT: ...
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the change here? I think pandas code has key and not item. Same in a few other places, not sure item is used that much in the pandas code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! The motivation was to keep pyrefly happy, which requires the param name identical to the one in the base class. But I believe we should really keep them identical to the one in pandas in the concrete implementation, which do not necessarily follow the pyrefly rule.

Incidently, in pandas there are overloads of the concrete implementation which have different param names than the ones in the concrete implementation. I've chosen to follow the concrete implementation.

d71f9ab

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically I have the following example:

from typing import overload


@overload
def foo(x: int) -> int: ...

@overload
def foo(x: str) -> str: ...

def foo(z: int | str):
    return z

foo(x=1)  # passes type check at this line, but fails at runtime

This is the implementation in DatetimeLikeArrayMixin.__getitem__ in 2.3.3. in main of pandas they have been made identical.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! The motivation was to keep pyrefly happy, which requires the param name identical to the one in the base class. But I believe we should really keep them identical to the one in pandas in the concrete implementation, which do not necessarily follow the pyrefly rule.

Incidently, in pandas there are overloads of the concrete implementation which have different param names than the ones in the concrete implementation. I've chosen to follow the concrete implementation.

I think the rule of thumb here that is equivalent is that the names we use in the stubs should also correspond to what is in the documentation, which I believe are also the names in the concrete implementation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@loicdiridollou
Copy link
Member

One minor question, rest looks good!

@cmp0xff cmp0xff marked this pull request as draft December 4, 2025 20:04
@cmp0xff cmp0xff marked this pull request as ready for review December 4, 2025 20:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants