`csv.Sniffer` fails on CR (`\r`) line endings due to hardcoded `split('\n')`

[ChuheLin]

Bug report

Bug description:

The csv.Sniffer._guess_delimiter method currently uses data.split('\n') to split lines.
This prevents it from correctly processing CSV data that uses Classic Mac (\r) line endings.

The Issue

Because split('\n') ignores \r, valid multi-line data using CR is interpreted as a single line.
This causes Sniffer to fail (raising Could not determine delimiter) or, in cases of mixed line endings (e.g., concatenated streams), to silently detect the wrong delimiter.

Reproduction

import csv

# Scenario 1: Pure CR data (Classic Mac / Legacy Systems)
# Sniffer sees 1 line instead of 2. Fails to determine delimiter.
sample_cr = "Name,Age\rAlice,30" 
try:
    csv.Sniffer().sniff(sample_cr)
except csv.Error as e:
    print(f"CR Failure: {e}")

# Scenario 2: Mixed endings (e.g. concatenated strings)
# Sniffer merges lines incorrectly, leading to SILENT DATA CORRUPTION.
# It detects '0' instead of ',' because ',' frequency becomes inconsistent.
sample_mixed = "User,ID\rAlice,001\nBob,002"
dialect = csv.Sniffer().sniff(sample_mixed)
print(f"Mixed Failure (Detected): {dialect.delimiter!r}")

Proposed Fix

Replace data.split('\n') with data.splitlines(). This aligns Sniffer's behavior with csv.reader, which correctly handles universal newlines (\r, \n, \r\n).

I have implemented the fix and added regression tests locally. Submitting a PR shortly.

CPython versions tested on:

CPython main branch, 3.11

Operating systems tested on:

Windows

Linked PRs

• gh-142188: Fix csv.Sniffer to handle CR and mixed line endings #142189

[picnixz]

I think it's a documented behavior: https://docs.python.org/3/library/csv.html#id4 (at least for files)

If newline='' is not specified, newlines embedded inside quoted fields will not be interpreted correctly, and on platforms that use \r\n line endings on write an extra \r will be added. It should always be safe to specify newline='', since the csv module does its own (universal) newline handling.

Note that the reader is hardcoded to recnogize \r or \n:

The reader is hard-coded to recognise either '\r' or '\n' as end-of-line, and ignores lineterminator. This behavior may change in the future.

So it's not correct to say that the reader handles \r\n which is the line terminator. I don't know if we should handle a string differently though (that is we sniff a string and not a file).

[picnixz]

In addition, this behavior has been like that since the beginning. Changing it doesn't strikes me as something required and could break other programs. I would recommend not changing this at runtime. In addition splitlines() is not correct because:

This method splits on the following line boundaries. In particular, the boundaries are a superset of universal newlines.