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.