Re: [gpsd-dev] Update on Python Version Compatibility

[Eric S. Raymond]

Fred Wright <address@hidden>:
> I did some poking around at Python in general, and identified the problem.
> It's not the overall default encoding that's the issue.  That remains
> utf-8 regardless of the environment (and would choke on *some* arbitrary
> binary data, anyway).  It's sys.stdout.encoding, which is derived from
> LANG, and defaults to US-ASCII when LANG is unset (or empty).

That is what I was expecting you to bring up. It's why, in Practical Python
Porting, part of the technique looks like this:

binary_encoding = 'latin-1'

def make_std_wrapper(stream):
    "Standard input/output wrapper factory function"
    # This ensures that the encoding of standard output and standard
    # error on Python 3 matches the binary encoding we use to turn
    # bytes to Unicode in polystr above; it has no effect on Python 2
    # since the output streams are binary
    if isinstance(stream, io.TextIOWrapper):
        # newline="\n" ensures that Python 3 won't mangle line breaks
        # line_buffering=True ensures that interactive command sessions work as 
expected
        return io.TextIOWrapper(stream.buffer, encoding=binary_encoding, 
newline="\n", line_buffering=True)
    return stream

sys.stdin = make_std_wrapper(sys.stdin)
sys.stdout = make_std_wrapper(sys.stdout)
sys.stderr = make_std_wrapper(sys.stderr)

> I've already tried this out in a separate test module; now I just need to
> apply it to the GPSD code.  Since it's needed by multiple modules, misc.py
> seems like the appropriate place for it (unlike the present
> polystr/polybytes, which are in client.py).

Your method would probably work.  However, I do *not* want the GPSD code
cluttered with artifacts from two subtly different sets of compatibility
shims.  That way lies madness.  It is unacceptable.

I am laying down ironclad policy now: we do polyglot code according to
the *documented methods* in Practical Python Porting.  If you want to
change GPSD's methods, you need to engage Peter Donis and me wearing
out HOWTO-author hats, persuade us to *change our recommendations*,
and then implement them over the whole GPSD corpus.

We won't be unreasonable about this.  You're a bright guy, you might
well have a better idea, and it wouldn't astonish me if you do. But
the thought of half-executing and not documenting such a change
*deeply* horrifies me.  I refuse any part of inflicting that technical
debt on future GPSD maintainers.

Peter Donis is <address@hidden>.  He invented most of the
techniques we described in Practical Python Porting; my main role
has been to wordsmith the document, keep an eye out for useful
additions, and merge them.  You should start by describing your
proposed technique to Peter (copying me), explaining what makes
it better, and proposing alterations to the HOWTO.

If you decide that's too much work, please stick with the existing
doctrine.  I understand your need to optimize the best way you think
you know how, but *I* need to defend the maintainability of the
codebase.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>