>> I noticed that text search wasn't working right on the bug tracker, and
>> Martin
>> has taken it offline again to re-index.
>
> which will, unfortunately, take a few more hours to complete.
It seems to work now, so I turned it on again. Text search now uses
Xapian, and recreating the Xapian
> Could you (with help from others who contributed) try to compile a table
> showing, for each platform (Windows/Mac/Linux/BSD) which clocks (or
> variations) we are considering, and for each of those:
>
> - a link for the reference documentation
> - what their typical accuracy is (barring jumps)
>
> Where in the stdlib do we actually calculate timeouts instead of using
> the timeouts built into the OS (e.g. select())?
At least in threading and queue modules. The common use case is to
retry a function with a timeout if the syscall was interrupted by a
signal (EINTR error). The socket module
Am 28.03.2012 23:55, schrieb R. David Murray:
> Since Martin hasn't sent a note about this here I will:
>
> I noticed that text search wasn't working right on the bug tracker, and Martin
> has taken it offline again to re-index.
which will, unfortunately, take a few more hours to complete.
Regar
Since Martin hasn't sent a note about this here I will:
I noticed that text search wasn't working right on the bug tracker, and Martin
has taken it offline again to re-index.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On Wed, Mar 28, 2012 at 2:36 PM, Scott Dial
wrote:
> On 3/28/2012 10:29 AM, Guido van Rossum wrote:
>> On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan wrote:
>>> Completely unintuitive and unnecessary. With the GIL taking care of
>>> synchronisation issues, we can easily coerce time.time() into bei
On Wed, 28 Mar 2012 20:56:30 -, "Jason R. Coombs" wrote:
> Will the release notes include something about this change, since it will
> likely have broad backward incompatibility for all existing virtualenvs? I
> wouldn't expect someone in operations to read the virtualenv news to find
> out wh
> I think the PEP should enumerate what platforms that CPython supports
> that will not benefit from a real monotonic clock. I think the number of
> platforms will be such a minority that the emulation makes sense.
> Practicality beats purity, and all.
The PEP lists OS monotonic clocks by platform
I'm personally +1 for pytz only — dateutil is big enough and...
Well, can we just point to pytz in our docs for datetime module?
On Thu, Mar 29, 2012 at 12:06 AM, Guido van Rossum wrote:
> +1 If pytz is py3k cabable. -1 for dateutIl.
>
>
> On Wednesday, March 28, 2012, Andrew Svetlov wrote:
>>
>
> Does this primarily give a high resolution clock, or primarily a
> monotonic clock? That's not clear from either the name, or the PEP.
I expect a better resolution from time.monotonic() than time.time(). I
don't have exact numbers right now, but I began to document each OS
clock in the PEP.
Vic
On 3/28/2012 10:29 AM, Guido van Rossum wrote:
> On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan wrote:
>> Completely unintuitive and unnecessary. With the GIL taking care of
>> synchronisation issues, we can easily coerce time.time() into being a
>> monotonic clock by the simple expedient of saving
> I would love to have only one new clock function in 3.3.
I already added time.clock_gettime() to 3.3 :-)
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
+1 If pytz is py3k cabable. -1 for dateutIl.
On Wednesday, March 28, 2012, Andrew Svetlov wrote:
> I figured out what pytz and dateutil are not mentioned in python docs
> for datetime module.
> It's clean why these libs is not a part of Python Libraries — but
> that's not clean for Docs.
> From m
> -Original Message-
> From: python-dev-bounces+jaraco=jaraco@python.org [mailto:python-
> dev-bounces+jaraco=jaraco@python.org] On Behalf Of Carl Meyer
> Sent: Wednesday, 28 March, 2012 14:48
>
> The workaround is easy: just re-run virtualenv on that path with the new
> interprete
I figured out what pytz and dateutil are not mentioned in python docs
for datetime module.
It's clean why these libs is not a part of Python Libraries — but
that's not clean for Docs.
From my perspective at least pytz (as py3k compatible) should to be
mentioned as the library which contains timezon
On 2012-03-28, at 1:55 PM, Yury Selivanov wrote:
> nonlocal _time
nonlocal _tick
obviously.
P.S. And we can make it to raise an error after some N calls
to time() resulting in lesser time that is stored in the _tick
variable.
-
Yury
___
Python-Dev ma
Hi Jason,
On 03/28/2012 12:22 PM, Jason R. Coombs wrote:
> To reproduce, using virtualenv 1.7+ on Python 2.7.2 on Ubuntu, create a
> virtualenv. Move that virtualenv to a host with Python 2.7.3RC2 yields:
>
> jaraco@vdm-dev:~$ /usr/bin/python2.7 -V
>
> Python 2.7.3rc2
>
> jaraco@vdm-dev:~$ env/
I see this was reported as a debian bug.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665776
We encountered it as well.
To reproduce, using virtualenv 1.7+ on Python 2.7.2 on Ubuntu, create a
virtualenv. Move that virtualenv to a host with Python 2.7.3RC2 yields:
jaraco@vdm-dev:~$ /
On 2012-03-28, at 11:35 AM, Nick Coghlan wrote:
> So, the primary use case is that we want to replace many of the
> time.time() calls in the standard library with time.monotonic() calls.
> To avoid backwards compatibility problems in the cross-platform
> support, that means time.monotonic() *must b
Am 27.03.2012 23:11, schrieb "Martin v. Löwis":
> Upfront hosting (Izak Burger) is going to do a Debian upgrade of the bug
> tracker machine "soon" (likely tomorrow). This may cause some outage,
> since there is a lot of custom stuff on the machine which may
> break with newer (Python) versions. I'
> What's wrong with "time.time()" again? As documented in
> http://docs.python.org/py3k/library/time.html it makes no guarantees,
> and specifically there is *no* guarantee that it will ever behave
> *badly*. Of course, we'll have to guarantee that, if a
> badly-behaved clock is available, users
On Wed, Mar 28, 2012 at 12:56, Victor Stinner wrote:
> There is time.hires() if you need a monotonic clock with a fallback to
> the system clock.
Does this primarily give a high resolution clock, or primarily a
monotonic clock? That's not clear from either the name, or the PEP.
//Lennart
___
Nick Coghlan wrote:
Completely unintuitive and unnecessary. With the GIL taking care of
synchronisation issues, we can easily coerce time.time() into being a
monotonic clock by the simple expedient of saving the last returned
value:
[snip]
Here's a version that doesn't suffer from the flaw of
On Thu, Mar 29, 2012 at 1:14 AM, Nick Coghlan wrote:
> That means choosing a name for the version that falls back to time()
> if monotonic() isn't available so it can be safely substituted for
> time.time() without having to worry about platform compatibility
> implications.
What's wrong with "ti
Matt Joiner wrote:
time.timeout_clock?
Everyone knows what that will be for and we won't have to make silly
theoretical claims about its properties and expected uses.
I don't.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
On Thu, Mar 29, 2012 at 1:47 AM, Guido van Rossum wrote:
> Where in the stdlib? (I'm aware of threading.py. Any other places?)
Victor had at least one other example. multiprocessing, maybe? I
believe the test suite may still have a few instances as well.
> But now consider a caching clock, and c
time.timeout_clock?
Everyone knows what that will be for and we won't have to make silly
theoretical claims about its properties and expected uses.
If no one else looks before I next get to a PC I'll dig up the clock/timing
source used for select and friends, and find any corresponding syscall th
On Wed, Mar 28, 2012 at 8:08 AM, Nick Coghlan wrote:
> On Thu, Mar 29, 2012 at 12:42 AM, Guido van Rossum wrote:
>> As I said, I think the caching idea is bad. We may have to settle for
>> semantics that are less than perfect -- presumably if you are doing
>> benchmarking you just have to throw a
2012/3/28 Guido van Rossum :
> Interesting bug. :-(
>
> It seems bugs.python.org is back up, so can you file it there too?
It took us weeks to track the bug. Here is the issue:
http://bugs.python.org/issue14432
Victor
___
Python-Dev mailing list
Python-
On Thu, Mar 29, 2012 at 1:02 AM, Yury Selivanov wrote:
> On 2012-03-28, at 10:45 AM, Nick Coghlan wrote:
>
>> On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov
>> wrote:
>>> What if system time jumps 1 year back? We'll have the same
>>> monotonic time returned for this whole year?
>>>
>>> I don't
On Thu, Mar 29, 2012 at 12:42 AM, Guido van Rossum wrote:
> As I said, I think the caching idea is bad. We may have to settle for
> semantics that are less than perfect -- presumably if you are doing
> benchmarking you just have to throw away a bad result that happened to
> be affected by a clock
On 2012-03-28, at 10:45 AM, Nick Coghlan wrote:
> On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov
> wrote:
>> What if system time jumps 1 year back? We'll have the same
>> monotonic time returned for this whole year?
>>
>> I don't think we should even try to emulate any of OS-level
>> function
On 2012-03-28, at 10:36 AM, Nick Coghlan wrote:
> Monotonicity is fairly easy to guarantee - you just remember the last
> value you returned and ensure you never return a lower value than that
> for the lifetime of the process.
As I said in my previous mail - I don't think we should ever do that.
On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov
wrote:
> What if system time jumps 1 year back? We'll have the same
> monotonic time returned for this whole year?
>
> I don't think we should even try to emulate any of OS-level
> functionality.
You have to keep in mind the alternative here: fall
Interesting bug. :-(
It seems bugs.python.org is back up, so can you file it there too?
On Wed, Mar 28, 2012 at 3:45 AM, Victor Stinner
wrote:
> Hi,
>
> bugs.python.org is down so I'm reporting the bug here :-)
>
> We have a crash in our product when tracing is enabled by
> sys.settrace() and th
On Wed, Mar 28, 2012 at 7:36 AM, Nick Coghlan wrote:
> On Wed, Mar 28, 2012 at 6:40 PM, Victor Stinner
> wrote:
>>> If we're simplifying the idea to only promising a monotonic
>>> clock (i.e. will never go backwards within a given process, but may
>>> produce the same value for an indefinite peri
On Wed, Mar 28, 2012 at 6:40 PM, Victor Stinner
wrote:
>> If we're simplifying the idea to only promising a monotonic
>> clock (i.e. will never go backwards within a given process, but may
>> produce the same value for an indefinite period, and may jump forwards
>> by arbitrarily large amounts),
>
On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan wrote:
> On Wed, Mar 28, 2012 at 8:56 PM, Victor Stinner
> wrote:
> In that case, I don't think time.try_monotonic() is really needed
> because we can emulate "time.monotonic()" in software if the platform is
> deficient.
As I wr
On 2012-03-28, at 10:17 AM, Nick Coghlan wrote:
> def _make_monotic:
> try:
> # Use underlying system monotonic clock if we can
> return _monotonic
> except NameError:
> _tick = time()
> def monotic():
> _new_tick = time()
>
On Wed, Mar 28, 2012 at 8:56 PM, Victor Stinner
wrote:
In that case, I don't think time.try_monotonic() is really needed
because we can emulate "time.monotonic()" in software if the platform is
deficient.
>>>
>>> As I wrote, I don't think that Python should workaround OS bugs. If
>>
Victor,
I have completely lost track of the details of this discussion. Could
you (with help from others who contributed) try to compile a table
showing, for each platform (Windows/Mac/Linux/BSD) which clocks (or
variations) we are considering, and for each of those:
- a link for the reference do
No, that would be time.monotonous(). This is time.monotonic(), the function
that can only play a single note at a time. Uh, I mean time.monophonic().
Hmm, this is harder than it looks.
On 28 March 2012 14:48, Matt Joiner wrote:
> time.monotonic(): The uneventful and colorless function.
> On Mar
time.monotonic(): The uneventful and colorless function.
On Mar 28, 2012 9:30 PM, "Larry Hastings" wrote:
> On 03/28/2012 01:56 PM, R. David Murray wrote:
>
>> On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano
>> wrote:
>>
>>> +1 on Nick's suggestion of try_monotonic. It is clear and obvious a
On 03/28/2012 01:56 PM, R. David Murray wrote:
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano wrote:
+1 on Nick's suggestion of try_monotonic. It is clear and obvious and doesn't
mislead.
How about "monotonicest".
(No, this is not really a serious suggestion.)
"monotonish".
Thus honor
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano wrote:
> +1 on Nick's suggestion of try_monotonic. It is clear and obvious and doesn't
> mislead.
How about "monotonicest".
(No, this is not really a serious suggestion.)
However, time.steadiest might actually work.
--David
_
Georg Brandl wrote:
On 28.03.2012 06:45, Nick Coghlan wrote:
On Wed, Mar 28, 2012 at 10:36 AM, Victor Stinner
wrote:
If QueryPerformanceCounter() is monotonic, the API can be simplified to:
* time.time() = system clock
* time.monotonic() = monotonic clock
* time.hires() = monotonic clock o
>>> In that case, I don't think time.try_monotonic() is really needed
>>> because we can emulate "time.monotonic()" in software if the platform is
>>> deficient.
>>
>> As I wrote, I don't think that Python should workaround OS bugs. If
>> the OS monotonic clock is not monotonic, the OS should be fi
Hi,
bugs.python.org is down so I'm reporting the bug here :-)
We have a crash in our product when tracing is enabled by
sys.settrace() and threading.settrace(). If a Python generator is
created in a C thread, calling the generator later in another thread
may crash if Python tracing is enabled.
On 3/28/2012 4:48 AM, Victor Stinner wrote:
>>> Scott> monotonic_clock = always goes forward but can be adjusted
>>> Scott> steady_clock = always goes forward and cannot be adjusted
>>>
>>> I don't know if the monotonic clock should be called time.monotonic() or
>>> time.steady(). The clock speed c
>> Scott> monotonic_clock = always goes forward but can be adjusted
>> Scott> steady_clock = always goes forward and cannot be adjusted
>>
>> I don't know if the monotonic clock should be called time.monotonic() or
>> time.steady(). The clock speed can be adjusted by NTP, at least on Linux
>> < 2.6
>> * time.time() = system clock
>> * time.monotonic() = monotonic clock
>> * time.hires() = monotonic clock or fallback to system clock
>>
>> time.hires() definition is exactly what I was trying to implement with
>> "time.steady(strict=True)" / "time.try_monotonic()".
>
> Please don't call the f
51 matches
Mail list logo
