Currently, the csv library calls str() on each value it writes. This can lead to surprising behavior, see issue40762 for example.

On the other hand, for writing the documentation says that the values must be strings or numbers.

The proposed "strict" argument would raise a TypeError if the supplied values are not strings, numbers, or None.

See https://github.com/python/cpython/blob/ba1c2c85b39fbcb31584c20f8a63fb87f9cb9c02/Modules/_csv.c#L1203 for where str() is called.

The documentation should be changed to note that None is allowed. Currently, None results in an empty string. I'm not proposing to change this, just document it as one of the allowed types.

How to check for "value is a number" needs to be decided.

For backward compatibility, strict would have to default to False.

I am +1 on with strict mode.
But I want to hear other core developers opinions.

I guess an isinstance check against numbers.Number would be the best way to check if an argument is a number. I'm not sure how convenient that is from C code.

There is PyNumber_Check(). It is not direct analog of isinstance(obj, numbers.Number), it checks that the object can be explicitly converted to the real number (int or float). UUID and IPv4Address pass this check.

As a narrow check we can use isinstance(obj, (str, int, float)). It does not accept Fraction, Decimal and numpy numbers, but it is what such modules like json or plistlib accept.

Losing Decimal would be a problem. I use those a lot in CSV files, and I assume others do, too.

We can check only nb_index and nb_float. It will include Fraction, Decimal and NumPy numbers and exclude UUID and IPv4Address.

That seems like a good plan.

Yes, converting Decimal to float can lose precision, so we cannot require this. PyNumber_Check() is already used for QUOTE_NONNUMERIC, so it would be logical to use it in determining that the object is a number in the cvs module.

But now the problem is with determining what is a "string". There is no way to check whether the object is "string-like", because virtually all objects can be converted to string. The only standard exception is bytes and bytearray for which str() may emit BytesWarning, so this conversion is not reliable. If restrict it only to an instance of str or its subclasses, it may break other user cases, for example writing Path in CVS.

I wouldn't have a problem with isinstance(obj, str) for a string check in strict mode. If you want to write something like a Path, convert it to a string yourself. That's exactly the behavior I'd like enforced by strict: only accept numbers and actual strings.