[issue27916] Use time.monotonic instead of time.time where appropriate

2019-03-11 Thread Cheryl Sabella


Cheryl Sabella  added the comment:

multiprocessing was changed to use time.monotonic in issue 34054.  Based on the 
other feedback on this thread, I'm going to close this.

--
nosy: +cheryl.sabella
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Ville Skyttä

Ville Skyttä added the comment:

Thanks for the explanation, understood. However, I don't think it would be 
terribly difficult to demonstrate that these changes do address actual pains(*) 
in the situations they're supposed to address them. And the pains in question 
might in real world occur quite rarely, unexpectedly, and take some time/cost 
to debug and reproduce, which is why it would be good to be able to 
preemptively address them.

(*) For some values of "pain" -- many of the changes here are just for 
outputting nice-to-know timing information.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Guido van Rossum

Guido van Rossum added the comment:

I mostly adhere to the rule of thumb "if it ain't broke, don't fix
it". So I would only endorse such changes if they address actual pain,
rather than possible pain.

Note that that rule of thumb was born out of worry about another
possible pain: the observation that some fraction of well-intentioned
fixes actually break something unanticipated. An (imagined) example in
this case: if someone mocks time.time() in a unit test, your fix
*might* break their test.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Ville Skyttä

Ville Skyttä added the comment:

It is not a wholesale search and replace, I have checked each change. There are 
a lot of places in the tree where monotonic is not appropriate, and those 
should not be included in the patch. But there is always the possibility that 
I've missed something, and it's good that there are reviewers.

Granted, some of the changes in this patch might not make a big difference, but 
they should not hurt either. To me, using monotonic is the right thing to use 
when dealing with time differences/delays, unless one needs an actual 
predictable time value anchored at the epoch at the same time for some other 
purposes. I don't of course insist on that point of view, and would be 
interested to hear other opinions and if someone can point out flaws/dangers in 
mine.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Guido van Rossum

Guido van Rossum added the comment:

asyncio already uses monotonic. The only place patched is a test
utility and I don't care either way. But I do think this is not a good
patch to do in general.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Raymond Hettinger

Raymond Hettinger added the comment:

Some of these look gratuitous to me, possibly a wholesale search and replace 
without detailed consideration of each change.  For example, the quick 
informational timing in random.py does not have any downside for using the 
regular time.time().  The changes to asyncio and multiprocessing may be 
warranted.

Davin, would you look at the multiprocessing portion of the patch?

Guido, can you nosy whoever the relevant maintainer is for the asyncio niggling 
details?

--
nosy: +davin, gvanrossum, rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Ville Skyttä

New submission from Ville Skyttä:

For better immunity against system clock changes.

--
files: monotonic.patch
keywords: patch
messages: 274036
nosy: scop
priority: normal
severity: normal
status: open
title: Use time.monotonic instead of time.time where appropriate
type: enhancement
Added file: http://bugs.python.org/file44304/monotonic.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com