str(bytes()) == repr(bytes()) and str(buffer()) == repr(buffer()) is
causing a bunch bugs which are extremely hard to understand. On several
occasions I didn't understand the problem until I removed a str() call
or made str(bytes()) and str(buffer()) raise an exception.

Err, please remove the (reprfunc) cast and check the language of the
error messages, too :)

Here is an updated patch that fixes an error in httplib that was causing
the xmlrpc test suite to block.

I'll look at the patches later, but we've gone over this before on the
list. str() of *any* object needs to return *something*. Yes, it's
unfortunate that this masks bugs in the transitional period, but it
really is the best thing in the long run. We had other exceptional
treatement for str vs. bytes (e.g. the comparison was raising TypeError
for a while) and we had to kill that too.

Guido van Rossum wrote:
> I'll look at the patches later, but we've gone over this before on the
> list. str() of *any* object needs to return *something*. Yes, it's
> unfortunate that this masks bugs in the transitional period, but it
> really is the best thing in the long run. We had other exceptional
> treatement for str vs. bytes (e.g. the comparison was raising TypeError
> for a while) and we had to kill that too.

Can we agree to a compromise and make str(bytes()) return
bytes().decode("ascii")? I think it's a sensible default behavior and
catches the errors in the code I've seen so far.

Christian

New patch:

static PyObject *
string_str(PyObject *op)
{
	return PyObject_CallMethod(op, "decode", "s", "ascii");
}

No -- making str(b) return b.decode("ascii") brings back the same issues
we had with mindlessly mixing PyString and PyUnicode in 2.x.  That was a
major disaster.

A compromise I could live with: add a command line option that makes it
a warning.

Guido van Rossum wrote:
> Guido van Rossum added the comment:
> 
> A compromise I could live with: add a command line option that makes it
> a warning.

Good idea. I can live with it, too. :) How do you like

-b: issue warnings about str(bytes_instance) and str(buffer_instance)
    (-bb: issue errors)

Christian

I've made a patch with -b -> warning and -bb > type error. I'm not happy
with the warning message. Maybe you've a better idea for it.

The error message is fine, though you could drop the word "Calling"
without loss of information. ;-) Also, most warnings don't seem to use
a trailing period.

Perhaps you could expand this to also add a trap in the comparison
function when Py{String,Bytes} is compared to PyUnicode.

Guido van Rossum wrote:
> The error message is fine, though you could drop the word "Calling"
> without loss of information. ;-) Also, most warnings don't seem to use
> a trailing period.
> 
> Perhaps you could expand this to also add a trap in the comparison
> function when Py{String,Bytes} is compared to PyUnicode.

It's sounds like a reasonable idea. But first I'm going to hit the down
with my gf and meet some friends. Cu later!

PS: In my humble opinion Amaury Forgeot d'Arc deserves an entry in the
Misc/ACKS list for his patches.

> It's sounds like a reasonable idea. But first I'm going to hit the down
> with my gf and meet some friends. Cu later!

No! You're not allowed to have a life! :-)

(And no hacking drunk, either. :-)

> PS: In my humble opinion Amaury Forgeot d'Arc deserves an entry in the
> Misc/ACKS list for his patches.

Agreed -- done!

Pfff! I've written my best code after having one or two beers :)

Updates:
* Added class BytesWarning(Warning)
* Added -b/-bb command line args and Py_BytesWarningFlag
* issue PyErr_WarnEx(PyExc_BytesWarning) when Py_BytesWarningFlag is set.
* Added warning filter for BytesWarning that raises an exception if
Py_BytesWarningFlag > 1

Open questions:
* the warning filter isn't set when the initializer cannot load the
warning module (e.g. frozen apps). W/o the warning module Python is
screwed anyway and frozen apps would never add the -b argument.
* the warnings are only enabled with -b. They can't be enabled by
modifying the warnings.filters. Is this fine with you?

> Updates:
> * Added class BytesWarning(Warning)
> * Added -b/-bb command line args and Py_BytesWarningFlag
> * issue PyErr_WarnEx(PyExc_BytesWarning) when Py_BytesWarningFlag is set.
> * Added warning filter for BytesWarning that raises an exception if
> Py_BytesWarningFlag > 1
>
> Open questions:
> * the warning filter isn't set when the initializer cannot load the
> warning module (e.g. frozen apps). W/o the warning module Python is
> screwed anyway and frozen apps would never add the -b argument.
> * the warnings are only enabled with -b. They can't be enabled by
> modifying the warnings.filters. Is this fine with you?

Yes, this is is all fine with me. Feel free to submit overnight.

Applied to py3k-pep3137 in r 58876