A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-October/029622.html below:

[Python-Dev] float atime/mtime/ctime - a bad idea?

[Python-Dev] float atime/mtime/ctime - a bad idea? [Python-Dev] float atime/mtime/ctime - a bad idea?Guido van Rossum guido@python.org
Wed, 16 Oct 2002 10:28:52 -0400
Barry:
> So then why not just make this an optional argument flag on the
> os.stat() call itself?  That way you could migrate some code at a
> different rate than other code (a global flag might be fine for your
> application, but break some 3rd party library you're using).

And Kevin:

> Please don't!  The global setting isn't sufficient since many of us
> access many 3rd party modules.

Most code doesn't care; most 3rd party code will work either way.
Martin proposed adding an option to the stat() call itself first, but
that seems a rather heavy-handed way to ensure backwards compatibility
for such a very rare situation.

If you are using a 3rd party library that breaks due to the floats,
you can disable the floats until you've got time to fix it.  You can
live with the ints a little longer.

--Guido van Rossum (home page: http://www.python.org/~guido/)



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