On Tue, Nov 22, 2016 at 06:31:45PM -0500, Glyph Lefkowitz wrote:
OK, this whole time I thought we were talking about a sensible application of text_type to the API, perhaps with some leniency for bytes-ish-ness on python 2. I haven't reviewed the PR, I was just responding to the concerns as raised on the list.
Sorry - I didn't mean to steer this towards API bike shedding.
If it's just randomly encoding on one version and not the other, and correct usage of the API depends on *users* doing 'if PY2:' in their own code, then perhaps Mark's concern is indeed well-founded and we should roll it back before 16.6.
Tristan's exactly right. Furthermore, if we decide to make IRCClient call its various command methods with unicode strings on Python 2, we'll be breaking backwards compatibility. This is what I meant when I wrote: On Nov 20, 2016, at 19:35, Mark Williams <markrwilliams@gmail.com> wrote:
Yes. Here's the lede: IRCClient should deal in bytes and we should introduce a ProtocolWrapper-like thing that encodes and decodes command prefixes and parameters. It should implement an interface, and we can start with an implementation that only knows about UTF-8. The obvious advantage of this is that you can more easily write IRCClients that work on both Python 2 and 3.
But it totally wasn't clear - sorry! Of course, I also want IRC client implementation that lets me get at bytes, but that's a discussion I'll move to a new thread. Given the inconsistency between Python 2 and Python 3, do we proceed with the revert? -Mark