2 different `Dialect` types - one in `csv` module and other in `_csv` module

[Dr-Irv]

Consider this code:

from csv import get_dialect


def foo(s: str):
    dialect = get_dialect(s)
    reveal_type(dialect)

mypy reports

dialects.py:6: note: Revealed type is "_csv.Dialect"

One would expect the result would be csv.Dialect.

There are 2 classes called Dialect in typeshed:

typeshed/stdlib/_csv.pyi

Line 28 in 2480d7e

class Dialect:

and

typeshed/stdlib/csv.pyi

Line 61 in 2480d7e

class Dialect:

get_dialect() is imported in csv.pyi from _csv.pyi, so the declaration in _csv.pyi is returning _csv.Dialect instead of csv.Dialect, so the type checkers see that as 2 separate classes.

[brianschubert]

Hmm, at a glance this seem to be accurate to the runtime behavior: there are actually two different Dialect classes, csv.Dialect vs _csv.Dialect, and csv.get_dialect() doess seem to return the latter:

>>> csv.get_dialect("excel")
<_csv.Dialect object at 0x7e438f29b800>

>>> isinstance(csv.get_dialect("excel"), csv.Dialect)
False
>>> isinstance(csv.get_dialect("excel"), csv._Dialect)
True

[Dr-Irv]

The docs say that get_dialect() returns a csv.Dialect so that's where the confusion is coming from.

[srittau]

This is a bit unfortunate, mostly because the implementation in Python is a bit hacky. We could in theory just declare csv.Dialect to be an alias of _csv.Dialect (or a sub-class), since their behavior is so similar, but that could leads to other problems. I would suggest to just add a note to csv.Dialect that this is often the wrong class and only used for sub-classing, and usually using _csv.Dialect is the correct option.