Eric S. Raymond
esr at thyrsus.com
Sun Nov 27 10:17:53 UTC 2016
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
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel