Python ntpq

[Eric S. Raymond]

Achim Gratz <Stromeko at nexgo.de>:
> > You have a point. Unfortunately there is no version-independent place
> > for Python libraries that the Python interpreter recognizes. And
> > there's a good reason for this - the bytecode used in .pyc/.pyo files
> > (the just-in-time compiled versions of .py files) differs across
> > versions.
> 
> Then it's not appropriate to make the choice of interpreter dependent on
> the vagaries of the PATH setting at the time of invocation as you do now
> by using env to find the binary.  Especially in the case the user built
> ntp with a specific python binary it might not be in path at all for the
> user(s) invoking the scripts.

Your point has merit.  But we don't know of a better option.  The theoretical
workarounds, like hacking hashbang lines at install time, turn out to be
horribly brittle in practice.

The Python devs are not stupid.  If there were a painless solution to this
problem it would be deployed already...

> > The only way I can think of to get near to what you want would be to set
> > a maximum width for the clockname field, implicitly bounding the amount the
> > display can extent to the right.
> 
> Yes, and please provide an option to set that width instead of trying to
> figure out a number that works for everyone.  Well, you can do that too,
> but I can guarantee that whatever number you come up with doesn't work
> for at least one person.

"One person" I don't care about.  I might if the --wide option didn't exist,
but since it does nobody is ever actually stuck with a truncating display.
I'll wait to see what the statistics on length distribution look like
before complicating things.

I'm in general not a fan of adding options as a subsitute for figuring out
what the right thing is.  It increases test and documentation complexity
too much when you do that casually.

> There is actually a much better solution: move the variable length field
> to the end of the line.

In theory, yes.  But not as a default - NTP users are conservative and
I don't want to deal with the grief I think I would get if I made that
large a change to the default layout.

>                     It also needs an option since it breaks
> compatibility (the wide display already does anyway since you can't
> parse the output using fixed columns anymore).

I'm not buying the second clause as a real problem. Nobody does that
kind of parsing with actual fixed fields as an assumption, not when
all modern scripting language make parsing by whitespace-separation
trivial.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>