Display cvs.Error without TypeError context

[smontanaro]

Bug report

Bug description:

Working my way through some documentation nits for the csv module, I noticed this method definition:

    def _validate(self):
        try:
            _Dialect(self)
        except TypeError as e:
            # We do this for compatibility with py2.3
            raise Error(str(e))

Why should we still try and maintain compatibility with Python 2.3 at this late date? Shouldn't we just let TypeError bubble up to the user?

CPython versions tested on:

3.13

Operating systems tested on:

macOS

Linked PRs

• gh-114628: Display csv.Error without context #115005

[gaogaotiantian]

I guess backward compatibility is a contagious thing. The comment might be out of date, but this is effectively the behavior from the ancient time until now. Changing that will not only break backward compatibility for Python 2.4, but also all the versions till 3.12.

[ericvsmith]

Right. I believe that comment can be read to say "Since this behavior goes back to at least Python 2.3, it can't be changed with a deprecation cycle". Maybe the comment should be changed to say that.

[terryjreedy]

csv.Error is a subclass of Exception. It is documented as being raised in 6 different methods. (Have not check if all true.) Many modules define their own exception or exceptions to raise in module methods. So csv is not exceptional in this, though it is inconsistent that ValueError is raised in a couple of places. The comment is obsolete and should be deleted. The other place Error is raised in based on 'if' instead of 'for' so the message is constructed directly instead of via an stdlib exception.

CSVError might have been a better name, and could even be added as an alias. But I would push for that here.

[ericvsmith]

I agree we should just delete the comment.

CSVError might have been a better name, and could even be added as an alias. But I would push for that here.

Do you mean "would not"? Otherwise I don't understand the "But" part of that sentence. I'd be against an alias, although I agree CSVError would have been better.

[smontanaro]

One other thing occurred to me. I'll accept that raising csv.Error is fine given the history and the long deprecation process required to change things. Could it not be raised while preserving the stack frames from the original TypeError though?

[terryjreedy]

would not

[terryjreedy]

Skip, in current Python, an exception raised within except by default gets the outer exception attached as .__context__ and both are displayed if the inner exception is not caught.

>>> csv.excel.delimiter = 1
>>> csv.excel()
Traceback (most recent call last):
  File "C:\Programs\Python313\Lib\csv.py", line 52, in _validate
    _Dialect(self)
TypeError: "delimiter" must be string, not int

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<pyshell#8>", line 1, in <module>
    csv.excel()
  File "C:\Programs\Python313\Lib\csv.py", line 48, in __init__
    self._validate()
  File "C:\Programs\Python313\Lib\csv.py", line 55, in _validate
    raise Error(str(e))
_csv.Error: "delimiter" must be string, not int

If one raises the inner exception from outer (see "The from clause"), the outer become the .__cause__ attribute. This changes the linking sentence ('During' above). If both tracebacks were useful, that would likely be preferable. However, in the above, the TypeError traceback is redundant and should be suppressed with from None. It is defective in that it does not show which Dialect subclass has the bad attribute. The csv.Error traceback does, which justifies re-raising.

I will make a PR revising the comment and adding 'from None'. The only other occurrence of raise Error in the file is in an if statement.

[terryjreedy]

While from None could have been added here anytime after being added in to Python in 3.3, it is not a bug that it had not been before. Hence no backport.

@smontanaro You are listed as inactive csv expert. You seem to be active again. Change back to active (delete (inactive))? Are you aware/involved with CSV Issues gh project? If so, OK if I add new field Type: General, Dialect, or Sniffer? to categorize issues?

[smontanaro]

@smontanaro You are listed as inactive csv expert. You seem to be active again. Change back to active (delete (inactive))? Are you aware/involved with CSV Issues gh project? If so, OK if I add new field Type: General, Dialect, or Sniffer? to categorize issues?

I'm really not interested in being "the CSV guy" (never really was, was just the last person involved). I retired several years ago and now mostly just noodle around with Python. I was more-or-less house-bound the past week or so, and stumbled on #101100, so spent some time there. I'll probably herd the few open tickets along, then get back to the other things I generally do with my time.

As for the CSV module, I could solve several of the items on that list by simply deleting the csv.Sniffer class, but I suppose we're stuck with it. I never liked or needed it.