On Wed, 23 Nov 2016 at 01:14 Tristan Seligmann <mithrandi@mithrandi.net> wrote:

On Tue, 22 Nov 2016 at 23:37 Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:

This is the part that I'm worried about. It kinda seems like we're moving toward "native string" being the type used in IRCClient, and that is capital-W Wrong. Native strings are for Python-native types only, i.e. docstrings and method names.

Unless I'm misunderstanding, we're not "moving towards" it, we have already arrived: IRCClient deals in str (bytes) on Python 2, and str (unicode) on Python 3. Even if we want a unicode API, having it only exist on Python 3 seems incredibly confusing from a user standpoint, and would appear to require some absurd contortions to write client code that behaves approximately the same on both Python 2 and 3.

For example, as far as I can tell, the only way to write code to join a channel named #tëst (UTF-8 encoded) is:

channel = u'#tëst'

if PY3:

channel = channel.encode('utf-8')

client.join(channel)

On Python 3, client.join(b'#t\xc3\xab') will try to send JOIN b'#t\xc3\xab', which is garbage, whereas on Python 2, client.join(u'#t\xebst') will produce a UnicodeEncodeError.