-
Notifications
You must be signed in to change notification settings - Fork 41
Type annotations #18
Comments
+1. My biggest annoyance has been with the repetition between types in the annotations and types in the docstrings. Presumably we could write a little decorator that pulls type-info from the function signature and puts them in the docstring (via a Jinja2 template or something). https://www.python.org/dev/peps/pep-0526/ (new syntax for variable annotations) was recently accepted for 3.6. Have we talked at all about what version of python3 we're targeting? Separate issue? |
I'm currently working with pycharm and autogenerated docstrings and function signatures (matplotlibs new |
I'm definitely in favor of this. have there been any decisions made about what python versions will be supported? @JanSchulz we might look into building a complimentary stub package for pycharm for matplotlib for the time being. auto-generated code is a huge pain. |
@brmc we would certainly take a type stub type of file (in the current |
For pandas 2, I think the plan is Python 3 only (see #5 ). |
type annotations would be quite useful for py2; these are also about the user api which is not likely to change much pandas2 is still a while off |
@jreback to be clear, I am all for starting early on annotations! This issue is on the pandas 2 tracker, though. |
@brmc so in reality this should be discussed on pandas-dev/pandas#14468 |
continuing conversation on pandas-dev/pandas#14468 |
Given that we seem to be on board with only supporting Python 3 (#5) in pandas 2.0, let's take full advantage of that and require type annotations for all internal pandas code. Users, of course, are free to ignore them as they please, but we can run mypy or pytype as part of our continguous integration tests to check for bugs.
Why?
Quite simply, this is just good software engineering.
The text was updated successfully, but these errors were encountered: