为什么csv.reader不被认为是一个类？

Question

From my understanding, an object is an instance of a class. So since csv.reader creates a reader object, I thought that it would be considered a class. I'm pretty new to this, so it would be helpful if someone could clarify this for me.

Answer 1

If something is an object, it's generally not a class It's like with animal species.

The dog named Cujo is of the species Dog, but Cujo isn't the species (category) itself. You can create a dog eg by:

dog = Dog ('Cujo')

I can have the class Dinosaur, but there are no living objects of that class around anymore.

Not only classes can return objects. I can have a function as follows:

def dog_factory (name):
    return Dog (name)

To create a dog with that, you can state:

dog = dog_factory ('Cujo')

While Dog is a class, dog_factory is just a function. It uses the class to create a dog.

If you ask for the class, using type (dog) , you'll see that dog is of class Dog, not of class dog_factory.

Don't be confused by the situation in JavaScript, if you happen to know that. Truly class-based languages like C++, Java, C# and Python are quite different, and in my view less contorted.

Answer 2

Not everything that creates an object is a class. Most callables that create objects aren't classes, and every callable returns an object unless it doesn't return anything at all (by throwing an exception, for example). For example,

def f():
    return []

creates and returns a list object, but it's not a class.

As for why csv.reader specifically wasn't written to be a class, that seems to be an artifact of the historical development of the csv module. The original PEP proposing the module says reader should be a function:

CSV readers are created with the reader factory function

but that just shifts the question from "why is reader not a class" to "why does the PEP say it shouldn't be a class", and the PEP doesn't give a rationale.

One possibility is to allow the factory function to return multiple reader types, although that doesn't seem to have ever been explored. Another hypothesis is that the module descends from code so old it had to use a factory function.

csv.reader returns instances of a reader type written in C , and the CSV PEP suggests that the code may be based on an earlier C module so old it predates type-class unification . Back before type-class unification, types written in C couldn't be called directly. You had to write a factory function to create instances of C types. This even extended to built-in types like list and int ; back then, names like list and int were instead factory functions that created list and int objects, rather than referring to the types themselves.

In Python 2.2, type-class unification made C types callable, but code designed with the earlier system in mind would still have factory functions and not necessarily any compelling reason to get rid of them.

Answer 3

From the PEP 305 :

CSV readers are created with the reader factory function:

obj = reader(iterable [, dialect='excel']
             [optional keyword args])

So csv.reader itself is technically a function , and not a class.

You might think it would make more sense if csv.reader was a class, and isinstance(my_reader, csv.reader) returned True , and I'd agree with you. That's how csv.DictReader does it:

>>> import io, csv
>>> reader = csv.DictReader(io.StringIO())
>>> isinstance(reader, csv.DictReader)
True

Unfortunately, the CPython code which defines the reader type and exposes it to the csv.py module was not carefully designed to be consistent with such conventions. Instead, csv imports the name reader from a _csv module , which is distributed as compiled code from an .so (binary) file. Historically, the all lowercase name referred to a C type , which explains the name _csv.reader instead of _csv.Reader .

Internally, a csv reader is an instance of the type(_csv.reader(...)) class, and that class itself is not exposed. So if you want to type-check it, you would need to do something hacky like this:

>>> import io, csv
>>> csv.Reader = type(csv.reader(io.StringIO()))
>>> isinstance(csv.reader(io.StringIO()), csv.Reader)
True

There's no particular reason the library developers couldn't have made the class public and called it csv.Reader , but that's not what happened. The csv module is about 15 years old at this time, and it predates the cleanup of Python's object model, when the naming conventions for types and classes had time to become better established.

Unfortunately, changing the interface from a csv.reader factory function into a csv.Reader class would break backwards compatibility.