[PATCH 1 of 2] util: disable floating point stat times (issue4836)

[Matt Mackall]

On Mon, 2015-11-30 at 17:10 -0500, Augie Fackler wrote:
> On Mon, Nov 30, 2015 at 02:49:30PM -0600, Matt Mackall wrote:
> > On Wed, 2015-11-25 at 16:09 -0800, Sean Farley wrote:
> > > Matt Mackall <mpm at selenic.com> writes:
> > > 
> > > > On Tue, 2015-11-24 at 17:56 -0600, Sean Farley wrote:
> > > > > Matt Mackall <mpm at selenic.com> writes:
> > > > > 
> > > > > > On Tue, 2015-11-24 at 13:32 -0500, timeless wrote:
> > > > > > > > +# disable Python's problematic floating point
> > > > > > > > timestamps
> > > > > > > > (issue4836)
> > > > > > > > +# (Python hypocritically says you shouldn't change
> > > > > > > > this
> > > > > > > > behavior
> > > > > > > > in
> > > > > > > > +# libraries, and sure enough Mercurial is not a
> > > > > > > > library.)
> > > > > > > 
> > > > > > > Presumably this is because it's neither threadsafe (i.e.
> > > > > > > it's
> > > > > > > process
> > > > > > > global, not per-thread), nor compatible w/ multiple
> > > > > > > libraries
> > > > > > > with
> > > > > > > different opinions about the behavior. i.e. if one
> > > > > > > library
> > > > > > > needs
> > > > > > > it
> > > > > > > off and one library needs it on, the two libraries will
> > > > > > > break
> > > > > > > each-other horribly.
> > > > > > 
> > > > > > It's obviously a bad idea for libraries to change this
> > > > > > because
> > > > > > programs
> > > > > > don't expect it to change. But Python's os module is itself
> > > > > > a
> > > > > > library,
> > > > > > so they're doing exactly what they tell people not to do.
> > > > > > 
> > > > > > (Admittedly, on a scale of compatibility breakage from 0 to
> > > > > > 3000
> > > > > > this
> > > > > > doesn't rate very high.)
> > > > > 
> > > > > Even for the wsgi apps?
> > > > 
> > > > Does Python or Python 3000 break wsgi apps? Yes. But I'm sure
> > > > that's
> > > > not actually your question.
> > > 
> > > I mean there are some wsgi apps that load Mercurial as a long-
> > > lived
> > > process. Basically, a library (Bitbucket and Kallithea would be
> > > two
> > > examples). Are we still going to change the global os module?
> > 
> > Yep, breaking third-party derived works that treats Mercurial as a
> > library continues to be a fact of life. Though I did forget to add
> > that
> > (API) flag to the commit, doh.
> 
> I'm a little worried about this change in the context of developer
> tools that embed Mercurial[0]. I feel like there has got to be a
> solution that doesn't gratuitously change stdlib behavior. If I can
> come up with something more graceful are you open to it?

I'm totally open to suggestions that meet the previously-expressed
constraints while miraculously still managing to exist.

-- 
Mathematics is the supreme nostalgia of our time.