py3 testcase fails coz of the change set proposed.
Considering a scenario for keystone.tests.unit.identity.backends.test_sql.TestIdentityDriver.test_authenticate_for_user_with_special_char with user_id='fl\xc3\xbcgel' (which actually is flügel, fl\xc3\xbcgel is the string representation in py2.)
In py3, as string/text means both ascii/unicode, fl\xc3\xbcgel as a user_id will mean flügel not mean flügel.
The string representation for flügel in py2 actually means flügel in string representation in py3. So, this unit test case might not be correct in the first place as user_id will not be 'fl\xc3\xbcgel' (can be this b'fl\xc3\xbcgel') when user is flügel.
py3 testcase fails coz of the change set proposed. tests.unit. identity. backends. test_sql. TestIdentityDri ver.test_ authenticate_ for_user_ with_special_ char with user_id= 'fl\xc3\ xbcgel' (which actually is flügel, fl\xc3\xbcgel is the string representation in py2.)
Considering a scenario for keystone.
In py3, as string/text means both ascii/unicode, fl\xc3\xbcgel as a user_id will mean flügel not mean flügel.
py3 console: fl\xc3\ xbcgel' , 'utf-8') = b'fl\xc3\ x83\xc2\ xbcgel'
print ('fl\xc3\xbcgel') -> flügel
print (u'fl\xfcgel') -> flügel
bytes(u'fl\xfcgel', 'utf-8') = b'fl\xc3\xbcgel'
bytes('
The string representation for flügel in py2 actually means flügel in string representation in py3. So, this unit test case might not be correct in the first place as user_id will not be 'fl\xc3\xbcgel' (can be this b'fl\xc3\xbcgel') when user is flügel.