com2ann: Convert type comments into Python type hints

[cclauss]

Description

https://pypi.org/project/com2ann

• Summary of the change / bug fix.
• Link # issue, if applicable.
• Screenshot of the feature or the bug before/after fix, if applicable.
• Relevant motivation and context.
• List any dependencies that are required for this change.

How has this been tested?

• Please describe the tests that you ran to verify your changes.
• Provide instructions so we can reproduce.
• Please also list any relevant details for your test configuration.

Checklist:

• Update our Hugo documentation following these guidelines.
• Update our tests following these guidelines.
• Make sure you are following our CONTRIBUTING guidelines.
• If a feature was added make sure to add it to the corresponding scripts file.

Others

• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• My code passes all the checks pylint, flake8, black, ... To speed up development you should run pre-commit install.
• New and existing unit tests pass locally with my changes. You can test this locally using pytest tests/....

[piiq]

What is the rationale to go away from using the typing module? The load time penalty is not that high but having 1 way to type hint the variables in the code improves readability through homogeneity by a lot. What am I missing @cclauss?

[cclauss]

@piiq Type hints are moving towards PEP 585 and PEP 604 and pyupgrade automatically makes these changes.

• https://github.com/asottile/pyupgrade#pep-585-typing-rewrites
• https://github.com/asottile/pyupgrade#pep-604-typing-rewrites

[piiq]

Thanks for pointing to the PEP. Is my understanding correct that:

1. Union[str,int] changes to str | int
2. Optional[str] changes to str | None (and the ~str proposal was not approved)
3. The from __future__ import annotations is going to stay there until the lowest supported version reaches 3.10?

[cclauss]

Yes for 1. and 2. but I think the jury is still out on 3. ... See the footnote https://docs.python.org/3/library/__future__.html

I have found it useful to run pyupgrade on various test files to understand its transformations.

[piiq]

Thanks. In that case I have another question. From your perspective is it possible to move away from typing module at all? Is there an Any annotation or an annotation for Callable?
I'm asking because I am ironically trying to follow the There should be one– and preferably only one –obvious way to do it. guiding principle

[cclauss]

PEP20:

There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

The Dutch part is significant here. The solution does not need to be too simplistic.

The community is not saying that we should completely abandon the typing module.

Instead, it advocates using pre-existing built-in types and the collections module types where possible. Having both List and list has confused new Python developers and it leads to unnecessary imports (both time complexity and code complexity). Similarly, having both typing.Callable and collections.abc.Callable suffers from the same issues. The proposed approach may take a bit of time to get used to but there is good logic behind this move.

[piiq]

Thanks for sharing your thoughts.
Would you mind updating the CONTRIBUTING.md to mention the change in how types should be used? And we can merge it