On Thu, Jun 21, 2012 at 12:57 AM, Nick Coghlan wrote:
>
> Standard assumptions about the behaviour of site and distutils cease to be
> valid once setuptools is installed
…
> - advocacy for the "egg" format and the associated sys.path changes that
> result for all Python programs running on a sys
On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing wrote:
>
> This is the strict mathematical meaning of the word "monotonic", but the way
> it's used in relation to OS clocks, it seems to mean rather more than that.
Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock.
There se
Folks:
Good job, Victor Stinner on baking the accumulated knowledge of this
thread into PEP 418. Even though I'm very interested in the topic, I
haven't been able to digest the whole thread(s) on the list and
understand what the current collective understanding is. The detailed
PEP document helps
On Mon, Mar 26, 2012 at 5:07 PM, Victor Stinner
wrote:
>>
>> If someone has a use case which fits the "steady or else fall back to wall
>> clock" pattern, I would like to learn about it.
>
> Python 3.2 doesn't provide a monotonic clock, so most program uses
> time.time() even if a monotonic cloc
> system_clock = wall clock time
> monotonic_clock = always goes forward but can be adjusted
> steady_clock = always goes forward and cannot be adjusted
> high_resolution_clock = steady_clock || system_clock
Note that the C++ standard deprecated monotonic_clock once they
realized that there is
On Fri, Mar 23, 2012 at 11:27 AM, Victor Stinner
wrote:
>
> time.steady(strict=False) is what you need to implement timeout.
No, that doesn't fit my requirements, which are about event
scheduling, profiling, and timeouts. See below for more about my
requirements.
I didn't say this explicitly eno
> I merged the two functions into one function: time.steady(strict=False).
>
> time.steady() should be monotonic most of the time, but may use a fallback.
>
> time.steady(strict=True) fails with OSError or NotImplementedError if
> reading the monotonic clock failed or if no monotonic clock is avail
The stat module uses the "st_ctime" slot to hold two kinds of values
which are semantically different and which are frequently
confused with one another. It chooses which kind of value to put in
there based on platform -- Windows gets the file creation time and all
other platforms get the "ctime"
On May 10, 2009, at 11:18 AM, Martin v. Löwis wrote:
If GNU stow solves all your problems, why do you want to use
easy_install in the first place?
That's a good question. The answer is that there are two separate
jobs: building executables and putting them in a directory structure
of the
On May 9, 2009, at 9:39 AM, P.J. Eby wrote:
It would be really straightforward, though, for someone to
implement an easy_install variant that does this. Just invoke
"easy_install -Zmaxd /some/tmpdir packagelist" to get a full set of
unpacked .egg directories in /some/tmpdir, and then move
On May 6, 2009, at 10:54 AM, Antoine Pitrou wrote:
Zooko Wilcox-O'Hearn zooko.com> writes:
I'm not thinking of API compatibility as much as data
compatibility -- someone used Python 3.1 to write down some
filenames, and now a few years later they are trying to use the
On May 6, 2009, at 7:33 AM, Stephen J. Turnbull wrote:
You have convinced me that the PEP should wait as well.
In its current form it is incomplete and dangerous.
+1 on delaying PEP 383
I think PEP 383 is a good idea in principle, but I'm still struggling
to understand it myself, and it se
12 matches
Mail list logo
