I don’t think changes to Python 2 are considered here, unless they are bug fixes, and this does not sound like a bug fix.

For Python 3, it sounds like you are proposing that str() accept encoding arguments even when not decoding from bytes. It sounds like this would mask the error if you called str(buffer, "ascii"), and the buffer happened to be an integer or a list, etc, by accident. Also, this woul

It seems str() is designed to have two separate modes:

1. str(object) is basically equivalent to format(object), with a warning if “object” happens to be a byte string or array

2. str(object, encoding, ...) is normally equivalent to object.decode(encoding, ...), or if that is not supported, codecs.decode(object, encoding, ...)

Your proposal sounds like it would make it easier to confuse these two modes. What should str(b"123", encoding=None) do? Why should the behaviour of str(file, encoding) vary depending on whether an ordinary file object or a memory-mapped file is passed?

IMO in a perfect Python 4 world, str() would only have a single personality (perhaps always returning an empty string, or a more strict conversion). Making a formatted string representations of arbitrary objects would be left to the format() and repr() functions, and decoding bytes to text would be left to the existing decode() methods and functions, or maybe a separate str.from_bytes() constructor, mirroring int.from_bytes().