CSV error reporting: logical record number or physical line range for multiline fields?

[renfengxing]

I would like feedback on an error-location design in a small Python standard-library CSV merge tool.

The parser accepts quoted multiline fields. For a field-count error it currently reports the source filename, logical record number (header is record 1), and the physical line where that record ends (csv.reader.line_num). A generated example produces:

{"status": "error", "error": "synthetic-invalid.csv: record 2, line 2: field count mismatch", "synthetic_demo": true}

For a multiline record, the physical line can differ from the record number. Would a start/end physical-line range be more useful when fixing an export in an editor, or would it create more confusion than a logical record number? A small synthetic example where the current location would be misleading would help.

The implementation is here, at the published commit; the local demo and format rules give the surrounding context. It validates UTF-8/comma-separated inputs with identical ordered headers and stops on bad input rather than writing a partial CSV. Whitespace is preserved by default; trimming is opt-in. The demo is synthetic, including the four-to-three-record trimming example.

Please use invented rows only, with no customer files, personal data or confidential information.

AI assistance: the code and drafting used Codex. This single post is prepared and submitted by an owner-authorized Codex assistant; the implementation details and demo behavior above were checked against the linked published source and recorded local execution results. The purpose is feedback on this specific reporting tradeoff.

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.