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/029614.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?Barry A. Warsaw barry@python.org
Wed, 16 Oct 2002 09:06:16 -0400
>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

    GvR> In this particular case, I think having a global flag should
    GvR> be good enough.  We can easily rig the standard library not
    GvR> to depend on its value.  It should be settable by calling a
    GvR> function, e.g.

    GvR>   os.stat_times(int)

    GvR> or

    GvR>   os.stat_times(float)

    GvR> If you think passing the actual type objects is too cute, we
    GvR> can call it stat_float_times() and pass a bool.

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).

-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