On Wed, 23 Nov 2016 at 01:14 Tristan Seligmann <mithra...@mithrandi.net>
wrote:
> On Tue, 22 Nov 2016 at 23:37 Glyph Lefkowitz <gl...@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.
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
