This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author larry
Recipients Alexander.Belopolsky, Arfrever, belopolsky, jcea, khenriksson, larry, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall, skrah, vstinner
Date 2011-09-11.14:21:52
SpamBayes Score 7.482903e-14
Marked as misclassified No
Message-id <1315750914.89.0.495142360946.issue11457@psf.upfronthosting.co.za>
In-reply-to
Content
Mark Dickinson:
> > I realize a new float type would be a major undertaking

> That's an understatement and a half.  The only way this could ever
> be viable is if float128 support becomes widespread enough that we
> don't have to write our own algorithms for basic float128 operations

As I mentioned earlier in this thread, GCC has supported __float128 since 4.3, Clang added support within the last year, and Intel has a _Quad type.  All are purported to be IEEE 754-2008 quad-precision floats.  Glibc added "quadmath.h" recently (maybe in 4.6), which defines sinq() / tanq() / etc.  Is that not sufficient?

The Windows compilers don't seem to support a float128 yet.  But Windows only supports 100ns resolution for mtime/atime anyway.  The bad news: according to my back-of-the-envelope calcuations, doubles will stop accurately representing 100ns timestamps in less than a year; they'll lose another bit of precision somewhere around 2019.


Alexander Belopolsky
> > How is this superior to using either Decimal or float128?

> It is explicit about the units of time used.  

Why is that a feature?  I'd rather that was abstracted away for me, like the os module currently does.


> And familiarity with C API is expected from users of os module, IMO.

As you say, that's your opinion.  But I've never heard of that as an official policy.  Therefore it is irrelevant as a design constraint for the API.


> > I've drawn an ASCII table summarizing the proposals so far.

> You did not mention "closely matches C API" as an upside.

By "C API", you mean "the POSIX-2008 compatible C API".  This would not match
 * POSIX platforms that don't meet the 2008 spec
 * Windows
 * Java
 * CLR
all of which are supported platforms for Python.

The documentation for the os module states:
"This module provides a portable way of using operating system dependent functionality. [...] The design of all built-in operating system dependent modules of Python is such that as long as the same functionality is available, it uses the same interface"

Since "the most recent modification time / access time of a file" is available on all platforms Python supports, it follows that Python should use the same interface to represent it on all those platforms.  Tying the representation to that of one particular platform is therefore poor API design, particularly when there are representations that abstract away such details within easy reach.

So I don't consider it a compelling upside--in fact I consider it a disadvantage.
History
Date User Action Args
2011-09-11 14:21:54larrysetrecipients: + larry, loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, vstinner, nadeem.vawda, Arfrever, r.david.murray, skrah, Alexander.Belopolsky, rosslagerwall, khenriksson
2011-09-11 14:21:54larrysetmessageid: <1315750914.89.0.495142360946.issue11457@psf.upfronthosting.co.za>
2011-09-11 14:21:54larrylinkissue11457 messages
2011-09-11 14:21:52larrycreate