>>> We must do better than Ruby: support arbritrary precision! :-D >> >> Seriously, I do consider that a necessary requirement for the PEP (which >> the Decimal type actually meets). (...) > > (...) > Not-quite-sure-how-seriously-you-intend-supporting-yoctoseconds-ly y'rs,
The point is not supporting yoctosecond resolution, but not having to change the API each time that the resolution becomes better. The time resolution already changed 3 times in UNIX/Linux history: 1 second, 1 ms, 1 us, 1 ns. So the C library has to maintain API for all these resolution: time_t, timeb, timeval, timespec... ftime() and usleep() are deperecated by POSIX 2008 for example. http://news.bbc.co.uk/2/hi/technology/5099584.stm "The prototype operates at speeds up to 500 gigahertz (GHz), more than 100 times faster than desktop PC chips." "A decade ago we couldn't even envisage being able to run at these speeds." 500 Ghz means a theorical resolution of 2 picoseconds (10^-12). So nanosecond might not be enough for next 10 years. This is theorical. In practive, Linux does already use nanosecond timestamps and shutil.copstat() has an issue with such timestamp (is unable to copy such timestamp with no loss of precision). Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
