`csv.get_dialect()` returns a `_csv.Dialect` object, not `csv.Dialect` as documented.

[Dr-Irv]

The documentation at https://docs.python.org/3/library/csv.html#csv.Dialect indicates that this class is what is returned when calling csv.get_dialect(). But the C implemented class _csv.Dialect() is returned instead.

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

This makes writing typesafe code that uses Dialect a challenge. See related typeshed issue at python/typeshed#14667

It's not clear whether this is a documentation or implementation issue.

[srittau]

One a cursory glace, _csv.Dialect and csv.Dialect seem to have the exact same behavior, so maybe the best solution is to just re-export _csv.Dialect from csv?

[srittau]

Well, not exact the same behavior. csv.Dialect can't be initialized, which _csv.Dialect can. And csv.Dialect does some validation hack (through _csv.Dialect) for Python 2.3(!) compatibility.

[picnixz]

I think it's deliberate. _csv.Dialect is not meant to be exposed. People aren't meant to use _csv.Dialect directly. Both classes are meant to follow the same protocol though so I think they should be considered interchangeable from an interface PoV instead (people aren't meant to instantiate a dialect)

[srittau]

Unfortunately that's quite confusing, and I assume an artifact from the before times where sub-classing C classes wasn't easy. The fact is that users are exposed to _csv.Dialect. For example isinstance(csv.get_dialect("excel"), csv.Dialect) returns False, because it's a _csv.Dialect. And I don't see a point in the extra Python-only class, which is basically identical to the C class (apart from disallowing initialization – but why even disallow that, what possible error does that prevent?)

[picnixz]

isinstance(csv.get_dialect("excel"), csv.Dialect)

I see, yes that could be annoying. Though, as it can only return a Dialect instance, I don't really see the point to do it (except for typing-related stuff).

And I don't see a point in the extra Python-only class, which is basically identical to the C class

It's to make sure that users correctly use the class attributes. Checking at the C level if the inherited class implements some attributes or not is still tricky (or maybe not?, for a subclass, we could check inside tp_new but I'm not entirely sure about this).

As such, I'm not sure we can entirely move a single interface of _csv.Dialect but I really don't want to expose the C class itself if we still have the Python one (and I would anyway don't want to expose it publicly).

Note that register_dialect also supports an inline form:

csv.register_dialect("foo", delimiter=':')
assert csv.get_dialect("foo").delimiter == ':'

Converting the output of csv.get_dialect to an instance of csv.Dialect instead of _csv.Dialect would require a lot of work on our side (we need to cache not an instance of _csv.Dialect but an instance of csv.<subclass>), which may become tricky as those instances would not be read-only anymore (I think).

Finally, I don't know if it's possible to make a subclass read-only when the base class is implemented in C. I think we can always bypass that with object.__setattribute__ if the subclass is written in pure Python. And we can't disallow subclassing either.