Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
Sorry, I disagree that this is a mere implementation detail. The term
"implementation detail" normally implies behaviour which occurs *by accident*
due to the specific implementation, rather than being intentionally chosen.
A good example is early versions of list.sort(), which was stable for small
lists only because the implementation happened to use insertion sort for small
lists. Insertion sort wasn't chosen because it was stable; had the
implementation changed to another sort, the behaviour would have changed.
(Later on, the implementation did change, and stability became a documented and
guaranteed feature.)
This is not what is happening here. The behaviour of for negative count doesn't
"just happen by accident" due to other, unrelated, choices. It happens because
the code intentionally tests for a negative count and replaces it with the
maximum value possible:
if (maxcount < 0)
maxcount = PY_SSIZE_T_MAX;
and it is documented in the C source code as a comment to argument clinic:
count: Py_ssize_t = -1
Maximum number of occurrences to replace.
-1 (the default value) means replace all occurrences.
https://github.com/python/cpython/blob/43682f1e39a3c61f0e8a638b887bcdcbfef766c5/Objects/unicodeobject.c#L12682
Some more evidence that this is intentional behaviour: in test_string.py, there
are various tests that -1 behaves the same as sys.maxsize, e.g.:
EQ("ReyKKjaviKK", "Reykjavik", "replace", "k", "KK", -1)
EQ("ReyKKjaviKK", "Reykjavik", "replace", "k", "KK", sys.maxsize)
That's not an isolated test, there are many of them.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39304>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
