[issue441357] time.clock() docs wrong for Windows

Change by admin : -- github: None -> 34754 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

Re: when uses time.clock,there are always mistakes

石盼 wrote: > The problem like this: > t = time.clock() > AttributeError: module 'time' has no attribute 'clock' Quoting https://docs.python.org/3/whatsnew/3.8.html#api-and-feature-removals """ The function time.clock() has been removed, after having been deprecate

Re: when uses time.clock,there are always mistakes

On 03/02/2020 08:04, 石盼 wrote: Hello ! 　The problem like this: 　 RESTART: Shell 　　>>> import time 　　>>> t = time.clock() 　　Traceback (most recent call last): 　

when uses time.clock,there are always mistakes

Hello ! 　The problem like this: 　 RESTART: Shell 　　>>> import time 　　>>> t = time.clock() 　　Traceback (most recent call last): 　 File "", line 1, in 　

[issue36895] time.clock() marked for removal in 3.8 – still there.

STINNER Victor added the comment: > time.clock() marked for removal in 3.8 – still there. Nope, it's now gone :-) I close the issue. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tra

[issue36895] time.clock() marked for removal in 3.8 – still there.

STINNER Victor added the comment: New changeset b6a09ae287e253e4146a5a224b75d4dbfd38cb63 by Victor Stinner (Matthias Bussonnier) in branch 'master': bpo-36895: Undocument removed time.clock (GH-13286) https://github.com/python/cpython/commit/b6a09ae287e253e4146a5a224b75d4dbfd38cb63

[issue36895] time.clock() marked for removal in 3.8 – still there.

STINNER Victor added the comment: New changeset 24482bd0ae203116fd7e41ec3219fb2857fb3ac7 by Victor Stinner (Matthias Bussonnier) in branch '3.7': [3.7] bpo-36895: document time.clock() has been removed in 3.8 (GH-13287) https://github.com/python/cpython/commit

[issue36895] time.clock() marked for removal in 3.8 – still there.

Matthias Bussonnier added the comment: Done: - 1 PR against master to remove the documentation and update api-and-feature-removals - and one against 3.7 to add the deprecated-removed. -- ___ Python tracker

[issue36895] time.clock() marked for removal in 3.8 – still there.

Change by Matthias Bussonnier : -- pull_requests: +13195 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36895] time.clock() marked for removal in 3.8 – still there.

Change by Matthias Bussonnier : -- pull_requests: +13193 stage: commit review -> patch review ___ Python tracker ___ ___

[issue36895] time.clock() marked for removal in 3.8 – still there.

Karthikeyan Singaravelan added the comment: Should this section also be updated about time.clock removal? https://docs.python.org/3.8/whatsnew/3.8.html#api-and-feature-removals -- nosy: +xtreak ___ Python tracker <https://bugs.python.

[issue36895] time.clock() marked for removal in 3.8 – still there.

STINNER Victor added the comment: I would prefer to remove time.clock() documentation if the function is removed. Would you mind to update Python 3.7 documentation to mention that the function is removed from Python 3.8? https://docs.python.org/3.7/library/time.html#time.clock In short, use

[issue36895] time.clock() marked for removal in 3.8 – still there.

Matthias Bussonnier added the comment: > If we find a _good_ reason to delay this removal a cycle during the 3.8 betas > we can bring it back. > thanks for staying on top of the removal plan! Thanks to you for the quick integration; I'm happy if we need to bring it back, but at least having

[issue36895] time.clock() marked for removal in 3.8 – still there.

Gregory P. Smith added the comment: I saw the PR before the bug comment. merged. if we find a _good_ reason to delay this removal a cycle during the 3.8 betas we can bring it back. thanks for staying on top of the removal plan! -- resolution: -> fixed stage: patch review ->

[issue36895] time.clock() marked for removal in 3.8 – still there.

Gregory P. Smith added the comment: New changeset e2500610c62673f42371b54fb0e4de83e4b33146 by Gregory P. Smith (Matthias Bussonnier) in branch 'master': bpo-36895: remove time.clock() as per removal notice. (GH-13270) https://github.com/python/cpython/commit

[issue36895] time.clock() marked for removal in 3.8 – still there.

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +13176 stage: -> patch review ___ Python tracker ___ ___

[issue36895] time.clock() marked for removal in 3.8 – still there.

Matthias Bussonnier added the comment: Vstiner, added you as you added the deprecation notice. I'm happy to take care of the removal and/or update the deprecation warning to 3.9. -- nosy: +vstinner ___ Python tracker

[issue36895] time.clock() marked for removal in 3.8 – still there.

New submission from Matthias Bussonnier : Deprecation message in `timemodule.c` says: > "time.clock has been deprecated in Python 3.3 and will be removed from Python > 3.8: use time.perf_counter or time.process_time instead" Should be bumped to 3.9 – or time.clock s

[issue31803] time.clock() should emit a DeprecationWarning

STINNER Victor <victor.stin...@gmail.com> added the comment: I read again the whole issue and I dislike the "time.clock becomes an alias to time.perf_counter" idea. Calling time.clock() now emits a deprecation warning, the issue is fixed, so I close it. Many discussions we

[issue31803] time.clock() should emit a DeprecationWarning

cause its behavior on other platform than used by the author of the > code. Not really, no. People who write cross-platform code are well aware of the differences of time.clock() and people who just write for one platform know how the libc function of the same function works on their platform.

[issue31803] time.clock() should emit a DeprecationWarning

Serhiy Storchaka added the comment: It is very bad, that the function with such attractive name has different meaning on Windows and Unix. I'm sure that virtually all uses of clock() are broken because its behavior on other platform than used by the author of the

[issue31803] time.clock() should emit a DeprecationWarning

STINNER Victor <victor.stin...@gmail.com> added the comment: Alexander Belopolsky: "I was not aware of time.clock() depreciation before Victor brought this issue to my attention." That's why the function now emits a DeprecationWarning :-) Alexander Belopolsky: "time.c

[issue31803] time.clock() should emit a DeprecationWarning

Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment: I would like to add my voice to MAL's objections. I was not aware of time.clock() depreciation before Victor brought this issue to my attention. time.clock() is a very well-known API eponymous to a venerable UNIX

[issue31803] time.clock() should emit a DeprecationWarning

Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment: This is the current behavior. Do you suggest to undeprecate time.clock() after 4 releases of deprecation? -- ___ Python tracker <rep...@bugs.python.org> <https://

[issue31803] time.clock() should emit a DeprecationWarning

erhiy's response that's time.process_time() on non-Windows platforms > and time.perf_counter() on Windows." > > I don't understand why you mean by "replaced with". Do you mean modify the > implementation of the time.clock()? What I meant is that time.clock() is repl

[issue31803] time.clock() should emit a DeprecationWarning

s platforms and time.perf_counter() on Windows." I don't understand why you mean by "replaced with". Do you mean modify the implementation of the time.clock()? I would like to kill time.clock() beceause it behaves differently on Windows and non-Windows platforms. There are two choice

[issue31803] time.clock() should emit a DeprecationWarning

Marc-Andre Lemburg <m...@egenix.com> added the comment: On 24.10.2017 11:23, STINNER Victor wrote: > > Marc-Andre Lemburg: "Thanks for pointing that out. I didn't know." > > Do you still think that we need to modify time.clock() rather than > deprecating it? Y

[issue31803] time.clock() should emit a DeprecationWarning

STINNER Victor <victor.stin...@gmail.com> added the comment: Marc-Andre Lemburg: "Thanks for pointing that out. I didn't know." Do you still think that we need to modify time.clock() rather than deprecating it? -- ___ Pyt

[issue31803] time.clock() should emit a DeprecationWarning

Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment: Yes, it is time.process_time(). This was the cause of adding two new functions time.perf_counter() and time.process_time() and deprecating (in the documentation only) time.clock(). On Windows time.clock() does includ

[issue31803] time.clock() should emit a DeprecationWarning

e time elapsed during sleep. > >>>> import time >>>> start = time.clock(); time.sleep(1); print(time.clock() - start) > 9.7001374e-05 >>>> start = time.perf_counter(); time.sleep(1); print(time.perf_counter() - >>>> start) > 1.00071

[issue31803] time.clock() should emit a DeprecationWarning

Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment: On non-Windows platforms clock() returns the processor time, perf_counter() does include time elapsed during sleep. >>> import time >>> start = time.clock(); time.sleep(1); print(time.clock() - star

[issue31803] time.clock() should emit a DeprecationWarning

hange the behavior of clock() on non-Windows platforms, it > should be done only after the period of emitting FutureWarning. Could you explain which behavior is changed by this on non-Windows platforms ? time.clock() only switches to a more accurate clock. That's pretty much it. Which clock it u

[issue31803] time.clock() should emit a DeprecationWarning

Ethan Furman added the comment: We definitely need time with either DeprecationWarning or FutureWarning before removing/substituting a function. -- ___ Python tracker

[issue31803] time.clock() should emit a DeprecationWarning

Serhiy Storchaka added the comment: This will break a code that depends on the current behavior on non-Windows platforms. And this will contradict the expectation of non-Windows programmers. If change the behavior of clock() on non-Windows platforms, it should be

[issue31803] time.clock() should emit a DeprecationWarning

STINNER Victor <victor.stin...@gmail.com> added the comment: I wrote the PR 4062 which removes time.clock() implementation: time.clock becomes an alias to time.perf_counter. haypo@selma$ ./python Python 3.7.0a2+ (heads/clock-dirty:16b6a3033e, Oct 20 2017, 18:55:58) >>&

[issue31803] time.clock() should emit a DeprecationWarning

Change by STINNER Victor : -- pull_requests: +4032 stage: resolved -> patch review ___ Python tracker ___

[issue31803] time.clock() should emit a DeprecationWarning

Marc-Andre Lemburg <m...@egenix.com> added the comment: On 18.10.2017 11:45, STINNER Victor wrote: > Marc-Andre, Ethan: What do you think of removing the deprecation warning from > the C (my last commit), leave the deprecation warning in the documentation, > and modify time.cl

[issue31803] time.clock() should emit a DeprecationWarning

STINNER Victor <victor.stin...@gmail.com> added the comment: "Initially the time module was a thin wrapper around C and OS time-related functions. It may be confusing that the behavior of time.clock() differs from the behavior of C's clock()." Well, the

[issue31803] time.clock() should emit a DeprecationWarning

Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment: Initially the time module was a thin wrapper around C and OS time-related functions. It may be confusing that the behavior of time.clock() differs from the behavior of C's clock(). The documentation for clock() on MSDN su

[issue31803] time.clock() should emit a DeprecationWarning

STINNER Victor <victor.stin...@gmail.com> added the comment: (I reopen the issue since the discussion is not over.) Marc-Andre Lemburg: "time.cock() is used in a lot of code." I ran a quick search on GitHub. I found different use cases of time.clock(): 1) Measure perform

[issue31803] time.clock() should emit a DeprecationWarning

s that only the delta between two values has a meaning." Currently time.clock() is the same clock than time.perf_counter() on Windows, but it's closer to CPU time as time.process_time() on Unix. time.perf_counter() and time.process_time() have a different name because the they are

[issue31803] time.clock() should emit a DeprecationWarning

Ethan Furman added the comment: I agree with MAL; removing functions just makes multi-version code more painful. At least have the DeprecationWarning active for two releases before removing it. -- nosy: +ethan.furman ___

[issue31803] time.clock() should emit a DeprecationWarning

Marc-Andre Lemburg added the comment: time.cock() is used in a lot of code. Why can't we simply replace the functionality with one of the other functions ? The documentation certainly allows for such a change, since it pretty much just says that only the delta between two

[issue31803] time.clock() should emit a DeprecationWarning

STINNER Victor <victor.stin...@gmail.com> added the comment: Ok, I modified time.clock() and time.get_clock_info('clock') to emit a DeprecationWarning. Let's wait for Python 3.8 to remove time.clock() ;-) Thanks for the reviews Serhiy Storchaka and Diana Clarke! -- reso

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

STINNER Victor <victor.stin...@gmail.com> added the comment: New changeset 884d13a55fc328e2e1e3948a82b361b30804b818 by Victor Stinner in branch 'master': time.clock() now emits a DeprecationWarning (GH-4020) https://github.com/python/cpython/commit/884d13a55fc328e2e1e3948a82b361b308

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

STINNER Victor <victor.stin...@gmail.com> added the comment: I proposed PR 4020 to emit a DeprecationWarning in time.clock() and time.get_clock_info('clock'). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

Change by STINNER Victor : -- pull_requests: +3995 ___ Python tracker ___ ___

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

Matthew Barnett added the comment: @Victor: True, people often ignore DeprecationWarning anyway, but that's their problem, at least you can say "well, you were warned". They might not have read the documentation on it recently because they have not felt the need to

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

STINNER Victor <victor.stin...@gmail.com> added the comment: Serhiy: "I think it is better to not remove time.clock() until EOL of 2.7. And in any case it first should start emitting a deprecation warning for a one or two releases." I really hate using 2.7 EOL as the final co

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

ts 3.3 and earlier versions at the same time. But now 3.2 is virtually out of use and I think we can start emitting a deprecation warning at runtime. And maybe make 2to3 replacing time.clock() with time.process_time() or time.perf_counter()? -- ___ Python t

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

STINNER Victor <victor.stin...@gmail.com> added the comment: Ben Hoyt: "... from the PR it's clear that the standard library and tests do too." I disagree here. The standard library doesn't use time.clock() since Python 3.3. Better clocks like time.perf_counter() or time.mon

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment: I think it is better to not remove time.clock() until EOL of 2.7. And in any case it first should start emitting a deprecation warning for a one or two releases. -- nosy: +benjamin.peterson, serhiy.sto

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

Ben Hoyt <benh...@gmail.com> added the comment: I don't think this is a good idea. I still use time.clock() out of habit (on Windows), and from the PR it's clear that the standard library and tests do too. I wouldn't be at all surprised to find others do as well. I realize it'

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

Change by Ned Deily : -- nosy: +belopolsky, lemburg ___ Python tracker ___ ___

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker ___ ___

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

STINNER Victor added the comment: With the PR, Python 3.7 will still requires the C clock() function to build on Unix, since time.process_time() uses it as the last fallback if all other functions failed. Maybe we can require to have other functions used by

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

Change by STINNER Victor : -- keywords: +patch pull_requests: +3992 stage: -> patch review ___ Python tracker ___

[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()

New submission from STINNER Victor <victor.stin...@gmail.com>: The behaviour of the time.clock() function is not portable: on Windows it mesures wall-clock, whereas it measures CPU time on Unix. Python has time.process_time() and time.perf_counter(), since Python 3.3, which are portable

[issue22749] remove obsolete remark in time.clock() docs

New submission from Akira Li: time.clock() documentation [1] says: this is the function to use for benchmarking Python or timing algorithms. and Deprecated since version 3.3: The behaviour of this function depends on the platform: use perf_counter() or process_time() instead, depending

[issue22749] remove obsolete remark in time.clock() docs

Georg Brandl added the comment: LGTM. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22749 ___ ___ Python-bugs-list mailing

[issue22749] remove obsolete remark in time.clock() docs

Roundup Robot added the comment: New changeset 5f086db3b51b by Georg Brandl in branch '3.4': Closes #22749: remove outdated advice to use clock() for accurate timing. https://hg.python.org/cpython/rev/5f086db3b51b -- nosy: +python-dev resolution: - fixed stage: - resolved status: open

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

Changes by Guido van Rossum gu...@python.org: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20475 ___

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

Roundup Robot added the comment: New changeset 38acef3c3228 by Guido van Rossum in branch 'default': Replace deprecated time.clock() with time.time(). Fixes issue #20475. http://hg.python.org/cpython/rev/38acef3c3228 -- nosy: +python-dev ___ Python

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

STINNER Victor added the comment: Instead of time.time, time.perf_counter would be better. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20475 ___

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

STINNER Victor added the comment: time.monotonic() has a bad resolution (15.6 ms) on Windows. To measure performances, use time.perf_counter() or time.process_time() as proposed in tome.clock() documentation. It depends if you want to include time elapsed during sleep. Usually

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

STINNER Victor added the comment: The problem with pystone is that such tool is used to compare performances between different versions of Python. If pystone uses a different clock in Python 3.4, you may not be able to compare compare results with older Python versions. In my opinion, such

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

Paul Sokolovsky added the comment: The problem with pystone is that such tool is used to compare performances between different versions of Python. That's why I just propose to switch it to time.time(), which surely is available on each and every Python version and implementation. If

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

STINNER Victor added the comment: That's why I just propose to switch it to time.time(), which surely is available on each and every Python version and implementation. It's not the same clock. time.clock() measures the process time, which is different from the wall clock time. Compare

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

Paul Sokolovsky added the comment: Yes, and my note about scientificity above. Also compare with your own account of time.perf_counter() above (Usually time.perf_counter() is the expected function.) Also, I didn't want to start discussion on how to do benchmarking right, just to point out a

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

amount of time. Besides, if time.clock() is deprecated, pystone will *have* to be modified one day, anyway. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20475

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

Antoine Pitrou added the comment: Paul: well, pystone has limits to its scientificity, it's more like quick- run-anywhere, there's pybench for real testing (it's maintained and supported I hope) pybench is so synthetic it's almost a nano-benchmark. I would suggest using the benchmarks

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

STINNER Victor added the comment: Besides, if time.clock() is deprecated, pystone will *have* to be modified one day, anyway. If something is changed, I would prefer to simply drop this old tool. It is not reliable and so may give you wrong results

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

Serhiy Storchaka added the comment: Pystone should has an option to specify a timer (as timeit). -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20475 ___

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

New submission from Paul Sokolovsky: http://docs.python.org/3.3/library/time.html#time.clock says that it's deprecated, but pystone.py in Python-3.4.0b3 tarball still uses it. Please kindly consider switching it to plain time.time() and not to some other novelties. My usecase is: I'm

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

Changes by Paul Sokolovsky pfal...@users.sourceforge.net: -- components: +Benchmarks versions: +Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20475 ___

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20475 ___ ___ Python-bugs-list

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

Yury Selivanov added the comment: Well, I guess we can replace from time import clock with something like try: from time import monotonic as clock except ImportError: from time import time as clock Victor, what do you think? -- nosy: +yselivanov

[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3

Changes by Yury Selivanov yselivanov...@gmail.com: -- nosy: +fdrake ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20475 ___ ___ Python-bugs-list

[issue14309] Deprecate time.clock()

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 314c3faea2fb by Victor Stinner in branch 'default': Close #14309: Deprecate time.clock() http://hg.python.org/cpython/rev/314c3faea2fb -- nosy: +python-dev resolution: - fixed stage: - committed/rejected

[issue14309] Deprecate time.clock()

STINNER Victor victor.stin...@gmail.com added the comment: The PEP 418 has been accepted: read it to understand why time.clock() is now deprecated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14309

[issue14309] Deprecate time.clock()

STINNER Victor victor.stin...@gmail.com added the comment: I misunderstood the time.clock() function. It counts the CPU time while the process is active, whereas a monotonic clock counts elapsed time even during a sleep. time.clock() and time.monotonic() are different clocks for different

[issue14309] Deprecate time.clock()

STINNER Victor victor.stin...@gmail.com added the comment: Something can be done to provide portable functions to get the user and system times. Lib/profile.py tests also various functions to choose the best one in Profile constructor. -- ___

[issue14309] Deprecate time.clock()

STINNER Victor victor.stin...@gmail.com added the comment: There's no other single function providing the same functionality time.clock() is not portable: it is a different clock depending on the OS. To write portable code, you have to use the right function: - time.time() - time.steady

[issue14309] Deprecate time.clock()

Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@gmail.com added the comment: There's no other single function providing the same functionality time.clock() is not portable: it is a different clock depending on the OS. To write

[issue14309] Deprecate time.clock()

Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@gmail.com added the comment: time.clock() has been in use for ages in many many scripts. We don't want to carelessly break all those. I don't want to remove the function, just mark

[issue14309] Deprecate time.clock()

Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: New submission from STINNER Victor victor.stin...@gmail.com: Python 3.3 has 3 functions to get time: - time.clock() - time.steady() - time.time() Antoine Pitrou suggested to deprecated time.clock

[issue14309] Deprecate time.clock()

STINNER Victor victor.stin...@gmail.com added the comment: time.clock() has been in use for ages in many many scripts. We don't want to carelessly break all those. I don't want to remove the function, just mark it as deprecated to avoid confusion. It will only be removed from the next major

[issue14309] Deprecate time.clock()

Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14309 ___ ___

[issue14309] Deprecate time.clock()

New submission from STINNER Victor victor.stin...@gmail.com: Python 3.3 has 3 functions to get time: - time.clock() - time.steady() - time.time() Antoine Pitrou suggested to deprecated time.clock() in msg120149 (issue #10278). The problem is time.clock(), since it does two wildly different

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

+=== + +The following functions have a new optional *timestamp* argument to get a +timestamp as a :class:`decimal.Decimal` instead of :class:`int` or +:class:`float`: + + * :mod:`time` module: :func:`~time.clock`, :func:`~time.clock_gettime`, + :func:`~time.clock_getres`, :func:`~time.time` and :func

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

at 0x7f46b9fe31e0' +Timestamp formats += + +:func:`time.clock`, :func:`time.clock_gettime`, :func:`time.clock_getres`, +:func:`time.time` and :func:`time.wallclock` now have an optional *format* +argument to choose the format of the timestamp. See the list of available +:ref:`timestamp formats

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

STINNER Victor victor.stin...@haypocalc.com added the comment: Hum, it looks like _PyTime_AsDecimal() is wrong is ts-divisor is not a power of 10. The exponent must be computed with Context(1), not Context(26). Something simpler can maybe be used, I don't know even the decimal API. --

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

as a keyword: time.time(format=decimal) I am not really conviced by the usefulness of timespec format, but it was just an example for #11457. The datetime format is surprising for time.clock() and time.wallclock(), these timestamps use an arbitrary start. I suppose that time.clock(format=datetime

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file24367/time_decimal-4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13882 ___

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

Alexander Belopolsky alexander.belopol...@gmail.com added the comment: On Sun, Jan 29, 2012 at 6:42 PM, STINNER Victor rep...@bugs.python.org wrote: .. What do you call a constant argument? float and decimal? You would prefer a constant like time.FLOAT_FORMAT? Or maybe a boolean

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

STINNER Victor victor.stin...@haypocalc.com added the comment: One possibility (still awkward IMO) would be to use the return type as the format specifier. Yeah, I already thaught to this idea. The API would be: - time.time(format=float) - time.time(format=decimal.Decimal) -

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

Alexander Belopolsky alexander.belopol...@gmail.com added the comment: On Mon, Jan 30, 2012 at 6:15 PM, STINNER Victor rep...@bugs.python.org wrote: Another possibility is what I proposed before in the issue #11457: take a callback argument. http://bugs.python.org/issue11457#msg143738 I

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

STINNER Victor victor.stin...@haypocalc.com added the comment: Constant arguments What do you call a constant argument? float and decimal? You would prefer a constant like time.FLOAT_FORMAT? Or maybe a boolean (decimal=True)? I chose a string because my first idea was to add a registry to

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

STINNER Victor victor.stin...@haypocalc.com added the comment: Patch version 4, minor update: - remove the resolution field of _PyTime_t and remove int_log10(): use 1/divisior as the resolution to support divisor different than a power of 10 (e.g. the cpu frequency on Windows) - inline and

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

Changes by STINNER Victor victor.stin...@haypocalc.com: -- assignee: - Arfrever Added file: http://bugs.python.org/file24367/time_decimal-4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13882

  1   2   3   >