Re: [gpsd-dev] GPSD and the Python 3 transition

[Eric S. Raymond]

Fred Wright <address@hidden>:
> > This does mean the floor Python version we can use is now 2.7; 2.6
> > is not compatible enough with 3.x for my polyglot trickery to work.
> 
> Which specific things don't work in 2.6?

There are some 3.x syntactic innovations that were backported into
2.7.2 and following that aren't allowed in 2.6 or very early
2.7s. Until, that is, a mob of pitchfork-wielding Pythonistas stormed
Dr. van Rossum's castle yelling "Give us back our forward
compatibility!", or something like that.

I think the "as" syntax for exception-catching was one of them, but
I've forgotten the details. It was a confusing time.  The Hammer Films
B-movie about it would be a real thrill-ride.

> > Current state of the Python code:
> >
> > gegps, gpscap.py, gpsfake, leapsecond.py, gps/*, maskaudit.py - OK under 2 
> > or 3.
> 
> At least one counterexample:
> 
> MacPro:gpsd fw$ python2 ./gpsfake -T
> sys darwin platform Darwin-13.4.0-x86_64-i386-64bit: WRITE_PAD = 0.03000
> MacPro:gpsd fw$ python3 ./gpsfake -T
> Traceback (most recent call last):
>   File "./gpsfake", line 17, in <module>
>     import gps.fake as gpsfake   # The "as" pacifies pychecker
>   File "/Volumes/MacPro-Misc/GitHub/gpsd/gps/fake.py", line 231
>     raise ValueError, line
>                     ^
> SyntaxError: invalid syntax

Yeah, I dropped a stitch there.  I think that's the module where 2to3
lost its cookies and I had to do all the low-level stuff by hand.  Oddly,
scons check passed, which is why I thought it was OK.

> > gpscat, test_maidenhead.py - don't work yet under Python 3, apparently
> > due to the clienthelpers C module not being installed where Python 3
> > can see it. Probably needs a build-recipe tweak.
> 
> I presume you were at least pointing python_libdir at the appropriate
> place for the Python 3 you were using, since the default (obtained from
> the scons Python) is guaranteed to be inappropriate for Python 3.

Hadn't got that far yet.  Solving the xgps problem was higher on my list.
But yes, I'd figured out the theory.

> In fact, although I'm not a fan of monoversioned shebang lines in general,
> given that Python packages are normally installed in a version-specific
> location, some means for writing the corresponding shebang lines into the
> installed executables should probably exist, at least as an option.

I am directly and strongly opposed to this.  Polyglot Python (that is, capable
of running under 2 or 3) is not difficult enough to write that the extra
layer of build complexity required to hack in version-specific shebang lines
is justified.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>