Ilja Everilä added the comment:
I'm starting to think my initial example code was too simplified and misled
from the issue at hand. It very explicitly showed what happens when some class
with __iter__ raises and is passed to csv_writerows. Even then:
>>> from collections.abc i
Ilja Everilä added the comment:
As a side note PyObject_GetIter actually raises a TypeError already for
non-iterables (classes without __iter__ etc.), so csv_writerows duplicates the
effort at the moment.
--
___
Python tracker
<h
Ilja Everilä added the comment:
I have 0 beef with it being the TypeError as long as the exception chain is
kept intact, especially since PY3 makes it possible. With current behaviour
heisenbugs would produce some serious hair pulling, until one figures out that
it is actually the __iter__
Ilja Everilä added the comment:
After doing some reading on https://docs.python.org/dev/c-api/exceptions.html
it seems that this is possibly "as designed" or such, since csv_writerows
explicitly calls PyErr_SetString on receiving NULL from PyObject_GetIter.
Still, it feels like
New submission from Ilja Everilä:
When passing a class implementing the dunder __iter__ that raises to
csv.writer.writerows it hides the original exception and raises a TypeError
instead.
In the raised TypeError the __context__ and __cause__ both are None.
For example:
>>> class X:
