Python 3 and 1.0

[Fred Wright]

On Tue, 26 Sep 2017, Eric S. Raymond wrote:

> Fred Wright via devel <devel at ntpsec.org>:
> > BTW, all the tests fail on FreeBSD, due to an undefined reference in
> > jigs.py.
>
> Huh? If so, why has this not shown up in the results from the FreeBSD buildbot.

I don't know, but what I see here is this:

$ cd ntpsec/
$ uname -a
FreeBSD MacFree 10.3-RELEASE-p20 FreeBSD 10.3-RELEASE-p20 #0: Wed Jul 12 03:13:07 UTC 2017     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
$ python -V
Python 2.7.13
$ ./build/main/tests/pylib/test_packet.py
Traceback (most recent call last):
  File "./build/main/tests/pylib/test_packet.py", line 15, in <module>
    import jigs
  File "/usr/home/fw/ntpsec/build/main/tests/pylib/jigs.py", line 175, in <module>
    class SocketModuleJig:
  File "/usr/home/fw/ntpsec/build/main/tests/pylib/jigs.py", line 185, in SocketModuleJig
    EAI_NODATA = socket.EAI_NODATA
AttributeError: 'module' object has no attribute 'EAI_NODATA'

I have no idea whether this affects anything real or whether it's just a
test artifact.  If the latter, it's clearly not a release blocker.

BTW, when I said "all the tests", that's not quite true.  I exclude the
agentx test due to its Python 3 issues, but it's not affected by this
particular bug.

I only see this on FreeBSD.  The tests work on OpenBSD, and the build
doesn't work on NetBSD due to the 6.1.5 issues.

> > Indeed.  When I started looking at the ntpq bug, I noticed that there
> > seemed to be some inconsistencies in whether 'response' was expected to be
> > str or bytes.  It doesn't matter in Python 2, of course.  But tossing in
> > enough polystr() and polybytes() calls to make the exceptions go away
> > isn't necessarily the best approach to making reliable code. :-)
>
> Unfortunately it's about the only recourse we have.  See
>
> http://www.catb.org/esr/faqs/practical-python-porting/
>
> for detailed discussion.

Yeah, I'm familiar with that document. :-) The point is that one should
try to understand what's going on and type things consistently, rather
than just ramdomly converting all over the place.  And since the Python
ntpq is a *new* program, it has less excuse for getting this wrong.

Fred Wright