It looks like the encode method for UserString incorrectly wraps its return value in a str call.

>>> from collections import UserString
>>> UserString("hello").encode('utf-8') == b'hello'
False
>>> UserString("hello").encode('utf-8')
"b'hello'"
>>> type(UserString("hello").encode('utf-8'))
<class 'collections.UserString'>

Trey, would you like to submit a PR to fix this? (Be sure to add a test case).

I think this is an easy issue. The relevant code is at

A simple unittest patch that fails on master. This can have additional tests with both encoding and errors present and both of them absent hitting all three code paths in the function.

diff --git a/Lib/test/test_userstring.py b/Lib/test/test_userstring.py
index 71528223d3..81a4908dbd 100644
--- a/Lib/test/test_userstring.py
+++ b/Lib/test/test_userstring.py
@@ -39,6 +39,11 @@ class UserStringTest(
# we don't fix the arguments, because UserString can't cope with it
getattr(object, methodname)(*args)

+ def test_encode(self):
+ data = UserString("hello")
+ self.assertEqual(data.encode(encoding='utf-8'), b'hello')

 if __name__ == "__main__":
     unittest.main()

I'll pick this up in the PyCon US 2019 sprint this afternoon.

I will pick this on up

My mistake, dfortunov is already working on this one.

PR submitted here:
#13138

Rather than adding three different tests for the different code paths I chose to collapse the three different code paths by surfacing the underlying str.encode() defaults in the method signature of UserString.encode(), taking it down to a one-line implementation.

@XTreak: Thanks for the super-helpful triage and failing test case!

New changeset 2a16eea by Raymond Hettinger (Daniel Fortunov) in branch 'master':
bpo-36582: Make collections.UserString.encode() return bytes, not str (GH-13138)
2a16eea

New changeset 2cb82d2 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-36582: Make collections.UserString.encode() return bytes, not str (GH-13138) (GH-15557)
2cb82d2