TYP: Add types to top-level funcs, step 2
State: closed

Next step to #30565.

Next up will be the pd.read_* functions.

Labels:
name: Typing
description: type annotations, mypy/pyright type checking

Comments:
Hello @topper-123! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:

















There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2020-01-05 12:20:24 UTC
I've overloaded ``concat``. mypy demands at least two overloads, which is strange. 

This is quite ugly, but allows us to drop the uglyness in other locations, so...:unamused:

> I've overloaded `concat`. mypy demands at least two overloads, which is quite strange.
> 
> This is quite ugly, but allows us to drop the uglyness in other locations, so...😒

the overloads do end up being ugly (and introduces duplication) but is more benefical for users of types since they don't need to include #ignores, casts or workarounds.
Yeah, I agree. It can be cleaned a bit when we reach 3.8. hopefully mypy will drop the duplication requirement.

The overload example in the python docs had no empty lines between overloaded definitions. Our Flake8 accepts that with a noqa directive, but pep8speaks doesn't. This is probaly not settled stylewise, but I like having no empty lines to signal the definitions belong together.

EDIT: Ok, while flake8 acceps no empty lines, black doesn't. So two empty lines it will be....
xref #26766
i think that’s a great idea 

Sent from my iPhone

> On Dec 31, 2019, at 10:55 AM, Simon Hawkins <notifications@github.com> wrote:
> 
> ﻿
> @simonjayhawkins commented on this pull request.
> 
> In pandas/core/reshape/concat.py:
> 
> > @@ -25,9 +25,28 @@
>  # ---------------------------------------------------------------------
>  # Concatenate DataFrame objects
>  
> +FrameOrSeriesUnion = Union["DataFrame", "Series"]
> maybe we should put this in _typing as FrameOrSeries and rename FrameOrSeries as FrameOrSeriesT. @WillAyd
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or unsubscribe.

I’ve made the changes.
PR updated.
I think @simonjayhawkins and I are proposing `FrameOrSeriesT` to denote a TypeVar version and go with a pseudo-standard of appending `T` for any TypeVars. Currently this is at `SameFrameOrSeries` which I am personally against as it is ambiguous what "Same" means

Is there a strong objection to the T standard?
I don’t have a strong opinion either way, but I think ‘FrameOrSeries’ and ‘FrameOrSeriesT’ are too similar; it will be unnecessary difficult to glance at the types. Maybe ‘NDFrameT’ (signals better where it actually comes from)? Or a differrent name for the union type.
> Maybe ‘NDFrameT’ (signals better where it actually comes from)?

prefer not. we may want to change this. see #29480
FrameOrSeries for the TypeVar and FrameOrSeriesUnion for the union? The union should be used sparingly, so less of a problem if that has a long name.
> FrameOrSeries for the TypeVar and FrameOrSeriesUnion for the union? The union should be used sparingly, so less of a problem if that has a long name.

sure
Is this ok to take in?
The failure looks unrelated, looks cython-related.
thanks !