[Python-Dev] float atime/mtime/ctime - a bad idea? (original) (raw)
Barry A. Warsaw barry@python.org
Wed, 16 Oct 2002 11:09:10 -0400
- Previous message: [Python-Dev] float atime/mtime/ctime - a bad idea?
- Next message: [Python-Dev] float atime/mtime/ctime - a bad idea?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> Most code doesn't care; most 3rd party code will work either
GvR> way. Martin proposed adding an option to the stat() call
GvR> itself first, but that seems a rather heavy-handed way to
GvR> ensure backwards compatibility for such a very rare
GvR> situation.
GvR> If you are using a 3rd party library that breaks due to the
GvR> floats, you can disable the floats until you've got time to
GvR> fix it. You can live with the ints a little longer.
But you may end up ping ponging between floats and ints as you import new libraries into your app. If, as you surmise, most code won't care, then that won't be a real problem. But if it is, you might see code like this:
ostate = os.stat_times()
os.stat_times(True)
try:
# do something requiring float times
finally:
os.stat_times(ostate)
Maybe it won't matter in practice, but global state like that always tickles the gag reflex in me. ;)
-Barry
- Previous message: [Python-Dev] float atime/mtime/ctime - a bad idea?
- Next message: [Python-Dev] float atime/mtime/ctime - a bad idea?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]