>>>>> "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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4