Éric Araujo added the comment:
A note in the docs (without note/warning directives, just a note) and maybe the
docstring would be good. It should better explain that str has two uses:
converting anything to a str (using __str__ or __repr__), decode buffer to str
(with encoding and errors arg
Antoine Pitrou added the comment:
Well, I forgot to mention it in my previous message, but there is already a
warning that you can activate with the -b option:
$ ./python -b
Python 3.3.0a0 (default:6b6c79eba944, Dec 6 2011, 11:11:32)
[GCC 4.5.2] on linux
Type "help", "copyright", "credits" o
R. David Murray added the comment:
A diff would be great.
We try to use warnings sparingly, and I don't think this is a case that
warrants it. Possibly a .. note is worthwhile, perhaps with an example for the
bytes case, but even that may be too much.
I also wouldn't use the wording "is tot
Guillaume Bouchard added the comment:
> str always falls back to the repr; in general str(obj) should always return
> some value, otherwise the assumptions of a *lot* of Python code would be
> broken.
Perhaps it may raises a warning ?
ie, the only reason encoding exists if for the conversion
Antoine Pitrou added the comment:
> Personally I'm not at all sure why str takes encoding and errors
> arguments (I never use them).
Probably because the unicode type also did in 2.x.
And also because it makes it compatible with arbitrary buffer objects:
>>> str(memoryview(b"foo"), "ascii")
'f
R. David Murray added the comment:
I agree with you that this is inconsistent. However, having str raise an error
is pretty much a non-starter as a suggestion. str always falls back to the
repr; in general str(obj) should always return some value, otherwise the
assumptions of a *lot* of Pyt
New submission from Guillaume Bouchard :
The docstring associated with str() says:
str(string[, encoding[, errors]]) -> str
Create a new string object from the given encoded string.
encoding defaults to the current default string encoding.
errors can be 'strict', 'replace' or 'ignore'
