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

Augie Fackler raf at durin42.com
Mon Nov 30 16:10:45 CST 2015


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?


0: I know the answer is officially "we don't care", but that kind of
attitude is actively harmful at this layer of coding, because now if
you're importing mercurial the *os module* starts exhibiting different
behavior for no obvious reason.

>
> --
> Mathematics is the supreme nostalgia of our time.
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list