CSV reader inconsistent with combination of QUOTE_NONNUMERIC and escapechar

[serhiy-storchaka]

>>> next(csv.reader([r'2\.5'], escapechar='\\', quoting=csv.QUOTE_NONNUMERIC))
[2.5]
>>> next(csv.reader([r'.5'], escapechar='\\', quoting=csv.QUOTE_NONNUMERIC))
[0.5]
>>> next(csv.reader([r'\.5'], escapechar='\\', quoting=csv.QUOTE_NONNUMERIC))
['.5']

It parses numbers with an escaped character in the middle, it parses numbers starting with a dot, but it does not parse numbers starting with an escaped character. The following variants would be more consistent:

1. Any escaped character disables parsing field as a number.
2. Allow parsing a field starting with an escaped character as a number.

Linked PRs

• gh-113785: csv: fields starting with escapechar are not quoted #122110
• [3.13] gh-113785: csv: fields starting with escapechar are not quoted (GH-122110) #122258
• [3.12] gh-113785: csv: fields starting with escapechar are not quoted (GH-122110) #122259

[MKuranowski]

I don't know which behavior is the expected one?

To go with the 1st option (any escapes prevent conversion), a self->numeric_field = 0; needs to be inserted at:

cpython/Modules/_csv.c

Line 724 in 3efcf66

case ESCAPED_CHAR:

The 2nd option requires if (dialect->quoting == QUOTE_NONNUMERIC) numeric_field = 1; added in here:

cpython/Modules/_csv.c

Line 702 in 3efcf66

else if (c == dialect->escapechar) {

[serhiy-storchaka]

I think why the escape character can be used at first place. QUOTE_NONNUMERIC does not affect escaping. If the character conflicts with one of special characters, it will be escaped, number it or not. If in future we will add support of using comma as decimal separator, there will be larger chance of conflict with field delimiter, so they should be escaped. Also, escapes can be necessary use some weird dialect with . or - as a field delimiter.

So I think that option 2 is more preferable.

[serhiy-storchaka]

@MKuranowski, do you mind to create a PR?