Skip to content

Various annotations extracted from #9511 #11092

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

Merged
merged 10 commits into from
Dec 4, 2023

Conversation

Avasam
Copy link
Collaborator

@Avasam Avasam commented Dec 1, 2023

Extracted from, and improved over #9511 to make these changes reviewable.
The following changes from #9511 is not present here:

  • Any change relating to cell values, Cell, MergedCell, ReadOnlyWorksheet, _WorkbookChild annotations and their subclasses that can't be explicitly known by looking at surface implementation (so new instances and isinstance checks)
  • Some return type changes (see Various annotations extracted from #9511 #11092 (comment))
  • 2 specialized Element Protocols that will be needed in stubs/openpyxl/openpyxl/worksheet/_reader.pyi
  • Descriptors in stubs/openpyxl/openpyxl/styles/styleable.pyi
  • to_tree methods (openpyxl: type to_tree methods #10967)

This comment has been minimized.

source: Incomplete
shared_strings: Incomplete
source: _FileRead
shared_strings: SupportsGetItem[int, Incomplete]
Copy link
Collaborator Author

@Avasam Avasam Dec 1, 2023

Choose a reason for hiding this comment

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

It doesn't feel right to have such a simple Protocol as an attribute, but openpyxl's own usage of it is extremely simple. I don't see the property being dynamically bound anywhere else. It's in a private module. And it's undocumented.
If someone reports needing it, we could make it generic.

@Avasam
Copy link
Collaborator Author

Avasam commented Dec 1, 2023

Ah fun /s, even if return types are accurate, it leads to errors if the value is fed back into a method that's still inaccurately only expects Worksheet. I'd rather update both at once to avoid introducing false-positives downstream. And updating those params is out of scope for this PR. So I'll revert some return type changes for now.

This comment has been minimized.

@Avasam Avasam changed the title Various annotations extraction from #9511 Various annotations extracted from #9511 Dec 1, 2023

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Copy link
Collaborator

@srittau srittau left a comment

Choose a reason for hiding this comment

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

Thanks, just one remark below.

Comment on lines 203 to 206
start_row: Unused = None,
start_column: Unused = None,
end_row: Unused = None,
end_column: Unused = None,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I wonder whether it would be safer to use : None = None here. It seems providing range_string and the rows and cols - while working at runtime - could introduce subtle bugs and is probably not what anyone wants.

But we should at least use ConvertibleToInt | None instead of Unused, because providing anything else (while working) is surely a bug.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok. I can see how passing both (which this allows) may lead to unexpected bug by not knowing which param is actually used. I'll move the concept that these params go unused in that overload as a comment instead of the parameter type.

@Avasam Avasam requested a review from srittau December 4, 2023 20:44
Copy link
Contributor

github-actions bot commented Dec 4, 2023

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

@srittau srittau merged commit 5521da8 into python:main Dec 4, 2023
@Avasam Avasam deleted the non-complex-extraction-from-9511 branch December 4, 2023 21:10
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.

2 participants