Currently str() takes up to 3 arguments. All are optional and
positional-or-keyword. All combinations are valid:
str()
str(object=object)
str(object=buffer, encoding=encoding)
str(object=buffer, errors=errors)
str(object=buffer, encoding=encoding, errors=errors)
str(encoding=encoding)
str(errors=errors)
str(encoding=encoding, errors=errors)
The last three are especially surprising. If you do not specify an
object, str() ignores values of encoding and errors and returns an empty
string.
bytes() and bytearray() are more limited. Valid combinations are:
bytes()
bytes(source=object)
bytes(source=string, encoding=encoding)
bytes(source=string, encoding=encoding, errors=errors)
I propose several changes:
1. Forbids calling str() without object if encoding or errors are
specified. It is very unlikely that this can break a real code, so I
propose to make it an error without a deprecation period.
2. Make the first parameter of str(), bytes() and bytearray()
positional-only. Originally this feature was an implementation artifact:
before 3.6 parameters of a C implemented function should be either all
positional-only (if used PyArg_ParseTuple), or all keyword (if used
PyArg_ParseTupleAndKeywords). So str(), bytes() and bytearray() accepted
the first parameter by keyword. We already made similar changes for
int(), float(), etc: int(x=42) no longer works.
Unlikely str(object=object) is used in a real code, so we can skip a
deprecation period for this change too.
3. Make encoding required if errors is specified in str(). This will
reduce the number of possible combinations, makes str() more similar to
bytes() and bytearray() and simplify the mental model: if encoding is
specified, then we decode, and the first argument must be a bytes-like
object, otherwise we convert an object to a string using __str__.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/YMIGWRUERUG66CKRJXDXNPCIDHRQJY6V/
Code of Conduct: http://python.org/psf/codeofconduct/
