Cut disused recode_encoding logic in _PyBytes_DecodeEscape.

[gnprice]

All call sites pass NULL for recode_encoding, so this path is
completely untested. That's been true since before Python 3.0.
It adds significant complexity to this logic, so it's best to
take it out.

All call sites now have a literal NULL, and that's been true since
commit 768921c eliminated a conditional (foo ? bar : NULL) at
the call site in Python/ast.c where we're parsing a bytes literal.
But even before then, that condition foo had been a constant
since unadorned string literals started meaning Unicode, in commit
572dbf8 aka v3.0a1~1035 .

The unicode parameter is already unused, so mark it as unused too.
The code that acted on it was also taken out before Python 3.0, in
commit 8d30cc0 aka v3.0a1~1031 .

The function (PyBytes_DecodeEscape) is exposed in the API, but it's
never been documented.

[benjaminp]

Is there a reason not to eliminate the unicode and recode_encoding parameters from _PyBytes_DecodeEscape completely?

[gpshead]

agreed, this is a static internal only function. just remove the unused parameters.

[benjaminp]

_PyBytes_DecodeEscape isn't static but the internal criteria still applies.

[gnprice]

Thanks both for the reviews!

just remove the unused parameters.

That sounds even better 🙂 The reason I hesitated is that these do appear in Include/bytesobject.h:

PyAPI_FUNC(PyObject *) PyBytes_DecodeEscape(const char *, Py_ssize_t, const char *, Py_ssize_t, const char *); #ifndef Py_LIMITED_API /* Helper for PyBytes_DecodeEscape that detects invalid escape chars. */ PyAPI_FUNC(PyObject *) _PyBytes_DecodeEscape(const char *, Py_ssize_t, const char *, Py_ssize_t, const char *, const char **); #endif 

and in particular PyBytes_DecodeEscape is outside any #ifndef Py_LIMITED_API block.

I wasn't sure changing the signatures would be acceptable, so I went for the most minimal change.

I'll update this PR to drop these parameters from _PyBytes_DecodeEscape, but leave them on PyBytes_DecodeEscape (I think that's what you're both suggesting.)

What are the criteria for saying an API is internal and can be freely changed? I see this one has two internal-flavored markings: the leading _ and the #ifndef Py_LIMITED_API. Is one of those considered definitive?

[benjaminp]

As described in https://docs.python.org/3/c-api/intro.html#include-files, no extensions should use _Py-prefixed names. Those names are not part of the public C API. (It would be better if installed headers defined only public interfaces, but that's not where we are today.) Py_LIMITED_API refers to a restricted subset of the public C API defined by PEP 384.

[gvanrossum]

Is there a reason not to eliminate the unicode and recode_encoding parameters from _PyBytes_DecodeEscape completely?

Well, it was also called from typed_ast/ast3/Python/ast.c (which is an external backport of ast.c and uses some internals like this one), but we're fixing that now, so no need to roll this back or anything. See python/typed_ast#128