Mark Dickinson wrote:
> I think this could work.

"could"?  Oh ye of little faith!

Attached is a patch against a nice fresh trunk (2b47f0146639) that adds Decimal attributes "ctime", "mtime", and "atime" to the object returned by os.stat().  The functions that consume mtime and atime values (os.utime, os.futimes, os.lutimes, os.futimesat) now also accept Decimal objects for those values.  My smoke-test using os.stat and os.utime works fine, and CPython passes the unit test suite with only the expected skippage.  However, the patch isn't ready to be checked in; I didn't update the documentation, for one.  I'd be happy to post the patch on Rietveld--just ask.

The implementation was complicated by the fact that Decimal is pure Python ;)  I had to do some "build the ship in a bottle" work.  Also, it's possible for os.stat to be called before the Python interpreter is really ready.  So internally it has to gracefully handle an import error on "decimal".

Along the way I noticed some minor resource leaks, both in os.utime:
  * for Windows, if passed a Unicode filename it would leak "obwpath".
  * for non-Windows, if the call to the C function utime() failed
    it would leak "opath".
I fixed these, along with a spelling error.

I also cleared up some sillyness.  When built on non-Windows, extract_time etc. used nine places of precision; on Windows it only used six.  Windows only calls extract_time for os.utime--the other functions that use extract_time aren't available on Windows.  And in the Windows implementation of os.utime, it multiplied the time it got from extract_time by a thousand!  This might even be throwing away some precision--not sure.  Definitely it was cruft.

However, modifying this meant changing the Windows code, which I can't test!  So I'm not 100% certain it's right.


Finally the bad news: this patch contributes a major performance regression on os.stat.  On my laptop, timeit says os.stat takes 10x longer when building the three Decimal fields.  My immediate thought: lazy-create them.  This would mean some major brain surgery; I'd have to make a subtype of PyStructSequence and override... something (tp_getattr? tp_getattro?).  (Though this might also neatly ameliorate the early-startup import problem above.)  I'd also have to hide the exact integers in the object somewhere--but since I'd be subclassing anyway this'd be no big deal.

My second thought: maybe one of the other Decimal constructors is faster?  I'm currently using the "parse a string" form.  My guess is, one of the other forms might be faster but not by an order of magnitude.


Martin van Löwis wrote:
> For example, gcc doesn't support __float128 in 32-bit
> mode on x86.

That was only true for GCC 4.3.  GCC 4.4 and newer support __float128 in 32- and 64-bit modes on Intel.  That release has been out for more than two years.

But consider the matter dropped ;-)