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

[Fred Wright]

On Tue, 29 Mar 2016, Eric S. Raymond wrote:

> Fred Wright <address@hidden>:
> > My original impression was that it's relevant even to top-level programs,
> > but upon rereading the doc, I guess not.  But I don't see it in gps/,
> > either.  This isn't about making it work, it's about setting it up so that
> > any future change that accidentally relies on implicit relative imports
> > fails the same way in Python 2 as it does in Python 3.
>
> I understand, but I don't grasp the full ramifications of the feature.
> I added the prefix dots required to make the gps/ module imports work under
> Python 3; is anything else required?

As I stated, this is about making Python3-incompatible implicit relative
imports fail in Python 2 as well.

It turns out this isn't purely academic.  The current import fixes to gps/
are incomplete, but the remaining failure is for the 'packet' module which
wasn't working for other reasons, anyway.  Adding the absolute_import
option to fake.py makes it fail in Python 2.

I must admit that I'm a bit puzzled by the form that works in __init__.py.
I'd expect it to want "from ." rather than "from .gps", with the bare dot
referring to the package directory, but the fact that the latter works and
the former doesn't indicates otherwise.  Perhaps __init__.py is a special
case that's processed before "descending" into the package directory.  In
any case, it's annoying to have to replicate the package name in the
imports (which is exactly the sort of thing that relative imports are
supposed to minimize).

Speaking of package-name prefixes, I noticed an inconsistency where the
module-name strings are specified as "packet" and "gps.clienthelpers".
So far, I haven't found anything authoritative on which is correct, and
neither choice seems to out-and-out break anything.  I did find one post
(which may or may not be applicable) suggesting that the former is
correct, and it's certainly more maintainable.  I did find some
documentation saying that the name field of *objects* (e.g. Lexer_Type)
should be the full-path-style name, but that's not exactly the same case.

Currently, I have both C extensions ostensibly working with Python 3, but
fake.py still needs work in the str vs. bytes area (previously untestable
without 'packet').

Fred Wright