You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat: Consider adding py.typed file marker for type-checking support #1126
I have lots of other projects to tackle at the moment, so it might be a while before I get around to this — because, if I understand correctly, I would need to not only add the py.typed file, but also generate basic stub files for each of Skyfield's .py files giving the types of its function and method calls?
Not necessarily! Adding py.typed is actually a two-step spectrum, it doesn't have to do everything at once.
The minimal approach is to just add an empty py.typed marker file to the package directory and include it in your package data. This alone signals to type checkers that the package opts into typing, and it stops the "stub file not found" warning. You wouldn't need any stub files for this. Of course, without actual type annotations or stubs, users would then get Unknown or Any types for most things, but that's already the situation today, just without the warning noise.
Over time type annotations could gradually be added to individual modules, no need to do it all in one shot.
Regarding Python 2.7 compatibility (which I understand it's still a concern), inline type annotations (the def foo(x: int) -> str: syntax) aren't available. But separate .pyi stub files that live alongside the .py files would work. These are only read by type checkers and never executed, so they can use modern Python 3 annotation syntax without affecting runtime compatibility at all.
So the smallest possible PR would literally be:
Create an empty skyfield/py.typed file
Ensure it's included in the distributed package
I am happy to get involved and help to get started with the effort
typing/timelib-module: to add stubs to timelib.py and all the files that it depends on. This is a fairly larger one and I can split it into multiple PRs if needed
Both these might not be perfect, but I think they would be a a good start to expose stubs and get users feedback
Activity
brandon-rhodes commentedon Apr 9, 2026
I have lots of other projects to tackle at the moment, so it might be a while before I get around to this — because, if I understand correctly, I would need to not only add the
py.typedfile, but also generate basic stub files for each of Skyfield's.pyfiles giving the types of its function and method calls?FBruzzesi commentedon Apr 9, 2026
Hey @brandon-rhodes thanks for getting back to me!
Not necessarily! Adding
py.typedis actually a two-step spectrum, it doesn't have to do everything at once.The minimal approach is to just add an empty
py.typedmarker file to the package directory and include it in your package data. This alone signals to type checkers that the package opts into typing, and it stops the "stub file not found" warning. You wouldn't need any stub files for this. Of course, without actual type annotations or stubs, users would then getUnknownorAnytypes for most things, but that's already the situation today, just without the warning noise.Over time type annotations could gradually be added to individual modules, no need to do it all in one shot.
Regarding Python 2.7 compatibility (which I understand it's still a concern), inline type annotations (the
def foo(x: int) -> str:syntax) aren't available. But separate.pyistub files that live alongside the.pyfiles would work. These are only read by type checkers and never executed, so they can use modern Python 3 annotation syntax without affecting runtime compatibility at all.So the smallest possible PR would literally be:
skyfield/py.typedfileI am happy to get involved and help to get started with the effort
FBruzzesi commentedon Apr 14, 2026
If #1127 gets accepts, I got a couple of follow ups already:
timelib.pyand all the files that it depends on. This is a fairly larger one and I can split it into multiple PRs if neededBoth these might not be perfect, but I think they would be a a good start to expose stubs and get users feedback