Repository navigation
Type Hints #1095
Description
Activity
I am absolutely open to receiving PRs adding type hints, and GitPython would be happy to host them directly in source.
Any amount of types would help and is appreciated, thus there is no need to add type hints everywhere at once.
I looked at starting to contribute type hints, but wanted to ask would it be feasible to drop support for python 3.4 (EOL 2 years ago)?
With 3.5+ type hints can be added directly to the code, but for 3.4 they would need to be in .pyi files, doubling the number of files and requiring they are kept in sync (AFAIK, 3.4 will give errors rather than ignore most inline type hints even though annotation syntax is possible)
@Yobmod Thanks for bringing this to my attention, and I would be glad to see type hints in code. Please feel free to submit a draft PR that starts out by dropping PY3.4 support to allow adding the first type hints in code. That one wouldn't have to be complete at all, but could lay the foundation for more PRs adding types in future.
I've put in a PR to drop python 3.4.
Planning to use Monkeytype to add initial types to the most user-facing files and see how that goes.A plan:
- Drop 3.4 (add 3.9)
- Final 3.4 release
- Monkeytype using test suite
- Add monkeytype.sqlite3 and mypy.ini to .gitignore
- Apply initial types to Repo/base & Repo/fun
- Add mypy.ini
- Add py.typed
- Appy initial types to git/*
- First typed release
- Appy initial types to index/*
- Appy initial types to refs/*
- Appy initial types to objects/*
- Increase mypy strictness
- Expand/Refine types (use overloads, Literals, TypedDicts etc)
- Make IterableList Generic & update throughout
- second typed release
- Drop 3.5 (add 3.10)
- Fix blocking issues caused by 3.5 compat
Thank for all the effort towards type hints! I am sorry I have not been able to contribute so far, I hope to be able to put some effort after the great initial start of @Yobmod
Thanks, Any help is always good :)
Branch for adding types is here: https://github.com/Yobmod/GitPython/tree/addtypes
Mypy-stubgen just typed everythin as Any, and Monkeytype has not been as useful as i hoped. If any wants to run it, commands are:
- monkeytype run test/tstrunner.py
- monkeytype list > mtype_filelist.txt
- monkeytype stub git.cmd > git/cmd.pyi
But i'm mostly doing them by hand.
Reacted by Sebastian Thiel, hodbn and Stefan SchablowskiReacted by Sebastian ThielHey, it seems that most of the code is typed, right? Would it be possible to include a "py.typed" file into the repo so that mypy can pick the types up?
Hey, it seems that most of the code is typed, right? Would it be possible to include a "py.typed" file into the repo so that mypy can pick the types up?
Hi, there already is one. Are you on the newest version?
Annotations showing up for me.Yes I use the latest version. The py.typed file is not present in the tar.gz nor in the wheel - maybe that's the issue.
Mypy (also latest version) complains that no stub could be foundI've read up on some setuptools options, it seems that the package_data and include_package_data arguments are mutually exclusive. So setup.py is picking up the package_data only from the MANIFEST.INI and not from within the setup.include_package_data list.
I'll add py.typed to the manifest and hopefully that fixes it.
Great. thanks a lot
I've installed from git and it puts the py.typed where it should be now.
If anyone wants the typehints before the next release, can do:pip install git+https://github.com/gitpython-developers/GitPython.git -UReacted by Sebastian Thiel37 remaining items
When running in strict mode one gets failures for the repository not exporting explicitly its properties:
Module "git" does not explicitly export attribute "Git"; implicit reexport disabledSee python/mypy#10198 (comment) for more details.
Yep, we have a lot of * imports that rely on implicit-reexport for mypy. For end-users this should not cause problems, but its a known mypy bug: python/mypy#8754.
If someone wants to change all the * imports to match
__all__for each module it will fix it, but otherwise have to wait for the bug to be fixed. Current workaround is if using--strict, also use--implicit-reexport.I personally think for reasons explained in python/mypy#10198 (comment) this is not a mypy bug 🤔 and I don't think due to that will be fixed 🤔 At best I'd imagine in
py.typedyou'd have some information about the package using implicit re-export but you cannot assume all packages will use that. Implicit re-export is a convenient but dangerous feature, and should be IMHO an opt-in not an always on thing.The issue for Orderdict though is that we are subclassing it, so one import has to be runtime available. Maybe we can put the typed versions in the
if TYPE_CHECKINGblock after the runtime import? It will still need py version guards for mypy though? it just wont break at runtime.Yes, I guess it will only prevent runtime issues but during type checking time, the imports must work. However, normal users might get more stable releases
So feel free to swap it for flake8-typing-imports and if it works (and once all errors are fixed/ignored) it can be added to test-requirements.txt.
Let me check and open a PR if possible. Please note, that these libraries are doing different things. The current one is more style related, while flake8-typing-imports checks import from typing based on the current python version
Seems useful already!
So we have to decide:
-
Drop 3.6 now,
-
or i'll pull out NamedTuple defaults (there are only a couple of uses) for now.
(NoReturn and Deque are available in typing_extensions, so that can be easily fixed.)
I was planning to wait until 3.10 released to drop 3.6.
But I see it had it's final release this June and i have noticed big packages already dropping it (numpy and pandas did last year and therefore most of scientific packages).-
Dropping py 3.6 seems like the path of least resistance.
I suggest to go with that.Reacted by kasiumIf someone wants to change all the * imports to match
__all__for each module it will fix it, but otherwise have to wait for the bug to be fixed. Current workaround is if using--strict, also use--implicit-reexport.See python/mypy#8754 (comment), seems this is not a bug in mypy, but a feature and the issue lies in this package, not the type checkers (both mypy and pyright seem to assume that implicit re-export is off).
If someone wants to change all the * imports to match
__all__for each module it will fix it, but otherwise have to wait for the bug to be fixed. Current workaround is if using--strict, also use--implicit-reexport.See python/mypy#8754 (comment), seems this is not a bug in mypy, but a feature and the issue lies in this package, not the type checkers (both mypy and pyright seem to assume that implicit re-export is off).
Its fixable here, but there are 156 implicit-reexports errors if its activated in the codebase atm, so it wont be done for the next few releases unless someone volunteers.
I've addedimplicit_reexport = trueto our settings, but I don't know if that will be overriden downstream?Is there any update how you want to proceed with this?
I think i've done everything I planned for the next release.
3.6 is dropped, and all reported errors in typing fixed and tested against an expanded test matrix. (Github actions only goes as early as 3.7.5 though).Testpypi uploads fine (using 3.7.3), so ready to go!
Thanks a lot! Thanks to a 'hickup' this was ultimately released as https://pypi.org/project/GitPython/3.1.23/ .
Reacted by Stefan Schablowski and Dominic- unpinned this issue
on Jan 7, 2022
Hello,
I was looking for any type hints for GitPython, but I found nothing neither in the code nor in independent stub repositories.
Is there any plan to introduce type hinting?