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

Fix more typing issues #1351

Merged
merged 10 commits into from
Feb 18, 2023
Merged

Fix more typing issues #1351

merged 10 commits into from
Feb 18, 2023

Conversation

alexrudd2
Copy link
Collaborator

I'm trying out mypy. This is still a WIP, although you can merge early if you want.

What should we do with implicit optional types? https://adamj.eu/tech/2022/10/18/python-type-hints-implicit-optional-types/

@alexrudd2 alexrudd2 marked this pull request as draft February 17, 2023 06:36
@janiversen
Copy link
Collaborator

I look forward to having mypy activity….at the very least for the api. Thanks a lot for taking this on.

I prefer to allow “implicit option types” that is writing “text: str = None” is allowed. Forcing “text: Optional[str, None] = None” is just a real PITA.

I am happy to review your stuff whenever you feel you have reached a level, where you want it merged. Just put it in review, and I will review/approve fast.

@jamesbraza
Copy link
Contributor

@janiversen fwiw, even though Optional is a bit ugly and expands signatures, it's recommended in PEP 484. The authors actually changed their minds on the implicit typing.

https://peps.python.org/pep-0484/#union-types

A past version of this PEP allowed type checkers to assume an optional type when the default value is None

This is no longer the recommended behavior. Type checkers should move towards requiring the optional type to be made explicit.

@janiversen
Copy link
Collaborator

janiversen commented Feb 17, 2023

I know that it is recommended, but it not demanded. We support 3.8+ so for us it would be a lot of useless typing, which do not make the code better or more readable.

Please remark this is just my opinion and in no way a demand.

Copy link
Collaborator

@janiversen janiversen left a comment

Choose a reason for hiding this comment

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

I think we should merge this soon to avoid having clashes with other pull requests. Making a merge after every 10-20 files sounds good to me.

It is a big job you have taken on, but it looks very very nice.

pymodbus/repl/server/main.py Show resolved Hide resolved
pymodbus/repl/server/main.py Show resolved Hide resolved
@alexrudd2
Copy link
Collaborator Author

I think we should merge this soon to avoid having clashes with other pull requests. Making a merge after every 10-20 files sounds good to me.

It is a big job you have taken on, but it looks very very nice.

OK, it should be ready to merge. mypy errors go from 111 -> 94 with this PR.

@alexrudd2 alexrudd2 marked this pull request as ready for review February 18, 2023 17:58
Copy link
Collaborator

@janiversen janiversen left a comment

Choose a reason for hiding this comment

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

A very good start. I did not know that typer() converted, thanks for testing it.

@janiversen janiversen merged commit bf152bb into dev Feb 18, 2023
@janiversen janiversen deleted the types branch February 18, 2023 18:35
@janiversen
Copy link
Collaborator

I merged the first part….looks very good to me.

Looking forward to see next part.

alexrudd2 added a commit to alexrudd2/pymodbus that referenced this pull request Feb 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants