[New-bugs-announce] [issue13538] Docstring of str() and/or behavior

[Guillaume Bouchard]

New submission from Guillaume Bouchard <guillaum.bouchard at gmail.com>:

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' and defaults to 'strict'.

When it is stated in the on-line documentation::

  When only object is given, this returns its nicely printable representation.

My issue comes when I tried to convert bytes to str.

As stated in the documentation, and to avoid implicit behavior, converting str to bytes cannot be done without giving an encoding (using bytes(my_str, encoding=..) or my_str.encode(...). bytes(my_str) will raise a TypeError). But if you try to convert bytes to str using str(my_bytes), python will returns you the so-called nicely printable representation of the bytes object).

ie. ::


  >>> bytes("foo")
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: string argument without an encoding
  >>> str(b"foo")
  "b'foo'"

As a matter of coherency and to avoid silent errors, I suggest that str() of a byte object without encoding raise an exception. I think it is usually what people want. If one wants a *nicely printable representation* of their bytes object, they can call explicitly the repr() function and will quickly see that what they just printed is wrong. But if they want to convert a byte object to its unicode representation, they will prefer an exception rather than a silently failing converting which leads to an unicode string starting with 'b"' and ending with '"'.

----------
components: Interpreter Core
messages: 148914
nosy: Guillaume.Bouchard
priority: normal
severity: normal
status: open
title: Docstring of str() and/or behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13538>
_______________________________________