Skip to content

Contributing Guide for Type Hints #27050

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

Merged
merged 15 commits into from
Aug 25, 2019
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Review comments
  • Loading branch information
WillAyd committed Jun 27, 2019
commit cc7cd4e5c90c2b76f47bb59cad48738bfb48a9fe
33 changes: 14 additions & 19 deletions doc/source/development/contributing.rst
Original file line number Diff line number Diff line change
Expand Up @@ -745,32 +745,17 @@ You should write

.. code-block:: python

from typing import Union
from typing import List, Union

maybe_primes = [] # type: Union[int, None]
maybe_primes = [] # type: List[Union[int, None]]

You should write

.. code-block:: python

from typing import Optional
from typing import List, Optional

maybe_primes = [] # type: Optional[int]

If a function accepts multiple arguments, every parameter should appear on a separate line. So rather than

.. code-block:: python

def some_func(a: str, b: float, c: Union[int, float]) -> float:

The preferred style would be

.. code-block:: python

def some_func(a: str,
b: float,
c: Union[int, float]
) -> float:
maybe_primes = [] # type: List[Optional[int]]

When dealing with parameters with a default argument of ``None``, you should not use ``Optional`` as this will be inferred by the static type checker. So instead of:
Copy link
Member Author

Choose a reason for hiding this comment

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

@jreback drawing your attention here as you might disagree

Copy link
Contributor

Choose a reason for hiding this comment

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

@jreback we are going with Optional or not?

Copy link
Contributor

Choose a reason for hiding this comment

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

do we have a code check for this?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm going to revert this section. Mypy supports this by default but it appears to be only for backwards compatibility and is considered a "mistake" in PEP 484

python/typeshed#1420

So separately can look into enabling --no-implicit-optional to see what breaks


Expand All @@ -789,6 +774,16 @@ Pandas-specific Types

Commonly used types specific to *pandas* will appear in pandas._typing and you should use these where applicable. This module is private for now but ultimately this should be exposed to third party libraries who want to implement type checking against pandas.
Copy link
Contributor

Choose a reason for hiding this comment

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

A small list of the types of things found here may be helpful (ArrayLike, Dtype, etc.)

I think inlining an example here would be very helpful; early on, contributors may be adding to this.

Copy link
Contributor

Choose a reason for hiding this comment

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

yes adding stuff in _typing.py sometimes confuses me. Some example will be nice.

Copy link
Contributor

Choose a reason for hiding this comment

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

can you put a reference to pandas._typing : https://github.com/pandas-dev/pandas/blob/master/pandas/_typing.py


For example, quite a few functions in *pandas* accept a ``dtype`` argument. This can be expressed as a string like ``"object"``, a numpy.dtype like ``np.int64`` or even a pandas ``ExtensionDtype`` like ``pd.CategoricalDtype``. Rather than burden the user with having to constantly annotate all of those options, this can simply be imported and reused from the pandas._typing module
Copy link
Contributor

Choose a reason for hiding this comment

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

can you use a ref to numpy.dtype


.. code-block:: python

from pandas._typing import Dtype

def as_type(dtype: Dtype) -> ...:

This module will ultimately house types for repeatedly used concepts like "path-like", "array-like", "numeric", etc... and can also hold aliases for commonly appearing parameters like `axis`. Development of this module is active so be sure to refer to the source for the most up to date list of available types.

Validating Type Hints
~~~~~~~~~~~~~~~~~~~~~

Expand Down