Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Paul Moore 
On 27 March 2012 01:23, Scott Dial  wrote:
> If you want to define new clocks, then I wish you would use the same
> definitions that C++0x is using. That is:
>
>  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

+1. This seems like an ideal case for following prior art in designing
a Python API.

Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Glyph 
On Mar 26, 2012, at 10:26 PM, Zooko Wilcox-O'Hearn wrote:

> Note that the C++ standard deprecated monotonic_clock once they
> realized that there is absolutely no point in having a clock that
> jumps forward but not back, and that none of the operating systems
> implement such a thing -- instead they all implement a clock which
> doesn't jump in either direction.

This is why I don't like the C++ terminology, because it seems to me that the 
C++ standard makes incorrect assertions about platform behavior, and apparently 
they standardized it without actually checking on platform capabilities.

The clock does jump forward when the system suspends.  At least some existing 
implementations of steady_clock in C++ already have this problem, and I think 
they all might.  I don't think they can fully fix it without kernel changes, 
either.  On linux, see discussion of a possible CLOCK_BOOTTIME in the future.  
The only current way I know of to figure out how long the system has been 
asleep is to look at the wall clock and compare, and we've already gone over 
the problems with relying on the wall clock.

Plus, libstdc++ gives you no portable way to get informed about system power 
management events, so you can't fix it even if you know about this problem, 
natch.

Time with respect to power management state changes is something that the PEP 
should address fully, for each platform.

On the other hand, hopefully you aren't controlling your python-based CNC laser 
welder from a laptop that you are closing the lid on while the beam is in 
operation.  Not that the PEP shouldn't address it, but maybe it should just 
address it to say "you're on your own" and refer to a few platform-specific 
resources for correcting this type of discrepancy.  
(, 
, 
).

-glyph

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Glyph 
On Mar 27, 2012, at 3:17 AM, Glyph wrote:

> I don't think they can fully fix it without kernel changes

I got really curious about this and went and did some research.  With some 
really platform-specific hackery on every platform, you can mostly figure it 
out; completely on OS X and Windows, although (as far as I can tell) only 
partially on Linux and FreeBSD.

I'm not sure if it's possible to make use of these facilities without a 
Twisted-style event-loop though.  If anybody's interested, I recorded the 
results of my research in a comment on the Twisted ticket for this: 
.

-glyph___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PendingDeprecationWarning

2012-03-27 Thread Ezio Melotti 
Hi,

On Thu, Mar 22, 2012 at 3:13 PM, Terry Reedy  wrote:
> My impression is that the original reason for PendingDeprecationWarning
> versus DeprecationWarning was to be off by default until the last release
> before removal. But having DeprecationWarnings on by default was found to be
> too obnoxious and it too is off by default. So do we still need
> PendingDeprecationWarnings? My impression is that it is mostly not used, as
> it is a nuisance to remember to change from one to the other. The
> deprecation message can always indicate the planned removal time. I searched
> the Developer's Guide for both deprecation and DeprecationWarning and found
> nothing.

See http://mail.python.org/pipermail/python-dev/2011-October/114199.html

Best Regards,
Ezio Melotti
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Lennart Regebro 
Reading this discussion, my conclusion is that not only us are
confused, but everyone is. I think therefore, that the way forward is
to only expose underlying API functions, and pretty much have no
intelligence at all.

At a higher level, we have two different "desires" here. You may want
a monotonic clock, or you may not care. You may want high resolution,
or you might not care. Which one is more important is something only
you know. Therefore, we must have, at the minimum, a function that
returns the highest resolution monotonic clock possible, as well as a
function that returns the highest resolution system/wall clock
possible. We also need ways to figure out what the resolution is of
these clocks.

In addition to that, you may have the requirement that the monotonic
clock also should not be able to jump forward, but if I understand
things correctly, most current OS's will not guarantee this. You may
also have the requirement that the clock not only does not jump
forward, but that it doesn't go faster or slower. Some clock
implementations will speed up or slow down the monotonic clock,
without jumps, to sync up with the wall clock. It seems only Unix
provides a monotonic clock (CLOCK_MONOTONIC_RAW) that does not get
adjusted at all.

Now between all these requirements, only you know which one is more
important? Do you primarily want a raw monotonic clock, and
secondarily high resolution, or is the resolution more important than
it being monotonic? (Because if you need a high resolution, you are
usually measuring small timeframes, and the clock is more unlikely to
be adjusted, for example).

Since there is no obvious "A is better than B that is better than C"
we first of all have to expose the underlying API's somehow, to allow
people to make their own decisions. Secondly, since apparently not
only python-dev, but many others as well, are a bit confused on this
complex issue, I'm not sure we can provide any high-level functions
that makes a best choice.

As such the proposed time.monotonic() to get the monotonic clock on
the various systems makes a lot of sense to me. It should get the
highest resolution available on the system. Get GetTickCount64() of
available on Windows, else GetTickCount(). The function could have a
raw=False parameter to select between clock_gettime(CLOCK_MONOTONIC)
and clock_gettime(CLOCK_MONOTONIC_RAW) on Unix, and it would get
mach_absolute_time() on OS X.

If no monotonic clock is available, it should raise an error.The same
if you pass in raw=True and there is no monotonic clock that has no
adjustments available.

In the same vein, time.time() should provide the highest resolution
system clock/wall clock available.

We also need functions or attributes to get the resolution of these clocks.


But a time.steady() that tries to get a "best case" doesn't make sense
at this time, as apparently nobody knows what a best case is, or what
it should be called, except that it should apparently not be called
steady(). Since monotonic() raises an error if there is no monotonic
clock available, implementing your own fallback is trivial in any
case.

//Lennart
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] how to uninstall python after 'make build'

2012-03-27 Thread Linker 
RT

thx.
linker
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Nick Coghlan 
On Tue, Mar 27, 2012 at 7:03 PM, Lennart Regebro  wrote:
> But a time.steady() that tries to get a "best case" doesn't make sense
> at this time, as apparently nobody knows what a best case is, or what
> it should be called, except that it should apparently not be called
> steady(). Since monotonic() raises an error if there is no monotonic
> clock available, implementing your own fallback is trivial in any
> case.

+1 from me to Lennart's suggestion of mostly just exposing
time.monotonic() without trying to get too clever. Applications that
need a truly precise time source should *never* be reading it from the
host OS (one fairly good solution can be to read your time directly
from an attached GPS device).

However, I think Victor's right to point out that the *standard
library* needs to have a fallback to maintain backwards compatibility
if time.monotonic() isn't available, and it seems silly to implement
the same fallback logic in every module where we manipulate timeouts.
As I concur with others that time.steady() is a thoroughly misleading
name for this concept, I suggest we encapsulate the "time.monotic if
available, time.time otherwise" handling as a "time.try_monotic()"
function.

That's simple clear and explicit: try_monotic() tries to use the
monotic clock if it can, but falls back to time.time() rather than
failing entirely if no monotonic clock is available. This is essential
for backwards compatibility when migrating any current use of
time.time() over to time.monotic(). Yes the monotonic clock is
*better* for many use cases (including timeouts), but you'll usually
be OK with the non-monotonic clock, too (particularly if that's what
you were using anyway in earlier versions). After all, we've survived
this long using time.time() for our timeout calculations, and bugs
associated with clock adjustments are a rather rare occurrence.

Third party libraries that need to support earlier Python versions can
then implementation their own fallback logic (since they couldn't rely
on time.try_monotonic being available either).

The 3.3 time module would then be left with three interfaces:

time.time() # Highest resolution timer available
time.monotonic() # I'm not yet convinced we need the "raw" parameter
but don't much mind either way
time.try_monotonic() # Monotonic is preferred, but non-monotonic
presents a tolerable risk

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Ethan Furman 

Nick Coghlan wrote:

The 3.3 time module would then be left with three interfaces:

time.time() # Highest resolution timer available
time.monotonic() # I'm not yet convinced we need the "raw" parameter
but don't much mind either way
time.try_monotonic() # Monotonic is preferred, but non-monotonic
presents a tolerable risk


+1

~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Yury Selivanov 
On 2012-03-27, at 9:23 AM, Nick Coghlan wrote:

> time.try_monotonic() # Monotonic is preferred, but non-monotonic
> presents a tolerable risk

This function seems unnecessary.  It's easy to implement it when
required in your application, hence I don't think it is worth
adding to the stdlib.

-
Yury
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Victor Stinner 
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.

I replaced time.steady() by time.try_monotonic(). I misunderstood "may
not" in the C++ doc: I understood it as "it may be adjusted by NTP",
whereas it means "it cannot be adjusted". Sorry for the confusion.

I added a time.hires() clock because time.monotonic() and
time.try_monotonic() are not the best clocks for profiling or
benchmarking. For example, on Windows, time.hires() uses
QueryPerformanceCounter() whereas time.monotonic() and
time.try_monotonic() uses GetTickCount[64]().

I added the pseudo-code of each function. I hope that it is easier to
understand than a long text.

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Victor Stinner 
> What is the utility of "strict=True"? If I wanted that mode of
> operation, then why would I not just try to use "time.monotonic()"
> directly?

I mentioned the strict=True API in the PEP just to list all
propositions, but the PEP only proposes time.monotonic() and
time.try_monotonic(), no the flags API.

> At worst, it generates an "AttributeError" (although that is not clear from 
> your PEP).

I tried to mention when a function is always available or not always
available. Is it better in the last version of the PEP?

>  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

I tried to follow these names in the PEP. I don't propose steady_clock
because I don't see exactly which clocks would be used to implement
it, nor if we need to provide monotonic *and* steady clocks. What do
you think?

> Straying from that is only going to create confusion. Besides that, the
> one use case for "time.steady()" that you give (benchmarking) is better
> served by a clock that follows the C++0x definition.

I added a time.hires() clock to the PEP for the benchmarking/profiling
use case. This function is not always available and so a program has
to fallback manually to another clock. I don't think that it is an
issue: Python programs already have to choose between time.clock() and
time.time() depending on the OS (e.g. timeit module and pybench
program).

> As well, certain
> kinds of scheduling/timeouts would be better implemented with the C++0x
> definition for "steady" rather than the "monotonic" one and vice-versa.

Sorry, I don't understand. Which kind of scheduling/timeouts?

The PEP is still a draft (work-in-progress).

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Victor Stinner 
> steady_clock:
>
>  mac = mach_absolute_time
>  posix = clock_gettime(CLOCK_MONOTONIC)
>  win = QueryPerformanceCounter

I read that QueryPerformanceCounter is no so monotonic, and
GetTickCount is preferred. Is it true?

> high_resolution_clock:
>
>  * = { steady_clock, if available
>        system_clock, otherwise }

On Windows, I propose to use QueryPerformanceCounter() for
time.hires() and GetTickCount() for time.monotonic().

See the PEP for other OSes.

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Victor Stinner 
2012/3/27 Jeffrey Yasskin :
> FWIW, I'm not sure you're the right person to drive time PEPs.

I don't want to drive the PEP. Anyone is invited to contribute, as I
wrote in my first message.

I'm completing/rewriting the PEP with all comments.

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Ethan Furman 

Yury Selivanov wrote:

On 2012-03-27, at 9:23 AM, Nick Coghlan wrote:


time.try_monotonic() # Monotonic is preferred, but non-monotonic
presents a tolerable risk


This function seems unnecessary.  It's easy to implement it when
required in your application, hence I don't think it is worth
adding to the stdlib.


If I understood Nick correctly, time.try_monotonic() is /for/ the 
stdlib.  If others want to make use of it, fine.  If others want to make 
their own fallback mechanism, also fine.


~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Victor Stinner 
> The clock does jump forward when the system suspends.  At least some
> existing implementations of steady_clock in C++ already have this problem,
> and I think they all might.
> 
> Time with respect to power management state changes is something that the
> PEP should address fully, for each platform.

I don't think that Python should workaround OS issues, but document
them correctly. I started with this sentence for time.monotonic():

"The monotonic clock may stop while the system is suspended."

I don't know exactly how clocks behave with system suspend. Tell me if
you have more information.

>  (,
> ,
> ).

I will read these links and maybe add them to the PEP.

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Victor Stinner 
> That's simple clear and explicit: try_monotic() tries to use the
> monotic clock if it can, but falls back to time.time() rather than
> failing entirely if no monotonic clock is available.

I renamed time.steady() to time.try_monotonic() in the PEP. It's a
temporary name until we decide what to do with this function.

I also changed it to fallback to time.hires() if time.monotonic() is
not available or failed.

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Michael Foord 

On 27/03/2012 18:45, Victor Stinner wrote:

[snip...]

Straying from that is only going to create confusion. Besides that, the
one use case for "time.steady()" that you give (benchmarking) is better
served by a clock that follows the C++0x definition.

I added a time.hires() clock to the PEP for the benchmarking/profiling
use case. This function is not always available and so a program has
to fallback manually to another clock. I don't think that it is an
issue: Python programs already have to choose between time.clock() and
time.time() depending on the OS (e.g. timeit module and pybench
program).


It is this always-having-to-manually-fallback-depending-on-os that I was 
hoping your new functionality would avoid. Is time.try_monotonic() 
suitable for this usecase?


Michael



As well, certain
kinds of scheduling/timeouts would be better implemented with the C++0x
definition for "steady" rather than the "monotonic" one and vice-versa.

Sorry, I don't understand. Which kind of scheduling/timeouts?

The PEP is still a draft (work-in-progress).

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk




--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Matt Joiner 
> I renamed time.steady() to time.try_monotonic() in the PEP. It's a
> temporary name until we decide what to do with this function.

How about get rid of it?

Also monotonic should either not exist if it's not available, or always
guarantee a (artificially) monotonic value. Finding out that something is
already known to not work shouldn't require a call and a faked OSError.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Playing with a new theme for the docs

2012-03-27 Thread PJ Eby 
On Mon, Mar 26, 2012 at 11:23 PM, Stephen J. Turnbull wrote:

> On Tue, Mar 27, 2012 at 1:35 AM, PJ Eby  wrote:
> > On Sun, Mar 25, 2012 at 2:56 AM, Stephen J. Turnbull  >
> > wrote:
> >>
> >> But since he's arguing the
> >> other end in the directory layout thread (where he says there are many
> >> special ways to invoke Python so that having different layouts on
> >> different platforms is easy to work around), I can't give much weight
> >> to his preference here.
> >
> >
> > You're misconstruing my argument there: I said, rather, that the One
> Obvious
> > Way to deploy a Python application is to dump everything in one
> directory,
> > as that is the one way that Python has supported for at least 15 years
> now.
>
> It's not at all obvious on any of the open source platforms (Cygwin,
> Debian,
> Gentoo, and MacPorts) that I use.  In all cases, both several python
> binaries
> and installed libraries end up in standard places in the distro-maintained
> hierarchies, and it is not hard to confuse the distro-installed Pythons.
>

Really?  I've been doing "dump the app in a directory" since 1998 or so on
various *nix platforms.  And when distutils came along, I set up a
user-specific cfg to install in the same directory.  ISTR a 5-line
pydistutils.cfg is sufficient to make everything go into to a particular
directory, for packages using distutils for installation.


Being confident that one knows enough to set up a single directory correctly
> in the face of some of the unlovely things that packages may do requires
> more knowledge of how Python's import etc works than I can boast:
> virtualenv is a godsend.  By analogy, yes, I think it makes sense to ask
> you
> to learn a bit about CSS and add a single line like "body { width: 65em;
> }" to
> your local config.  That's one reason why CSS is designed to cascade.
>

That line won't work - it'll make the entire page that width, instead of
just text paragraphs.  (Plus, it should only be the *maximum* width - i.e.
max-width.) Unfortunately, there's no way to identify the correct selector
to use on all sites to  select just the right elements to set max-width on
- not all text is in  "p", sometimes preformatted text is in a p with
styles setting the formatting to be preformatted.

(In other words, I actually do know a little about CSS - enough to know
your idea won't actually work without tweaking it for different sites.  I
have enough Greasemonkey scripts as it is, never mind custom CSS.)


> The comparison to CSS is also lost on me here; creating user-specific CSS
> is
> > more aptly comparable telling people to write their own virtualenv
> > implementations from scratch, and resizing the browser window is more
> akin
> > to telling people to create a virtualenv every time they *run* the
> > application, rather than just once when installing it.
>
> Huh, if you say so -- I didn't realize that virtualenv did so little that
> it could be written in one line.


Around 3-5 lines for dumping everything into a single directory.  If you
need multiple such directories at any one time, you can alternately pass
--install-lib and --install-scripts to "setup.py install" when you install
things.  Or you can use easy_install and just specify the -d
(--install-dir) option.

Or, you could use the PYTHONHOME solution I described here in 2005:


http://svn.python.org/view/sandbox/trunk/setuptools/EasyInstall.txt?r1=41220&r2=41221

Ian Bicking turned those instructions into a script, which he then
gradually evolved into what we now know as virtualenv.

Before that happened, though, I was deluged with complaints from people who
were using "dump it in a directory somewhere" on *nix platforms and didn't
want to have anything to do with those danged newfangled virtual
whatchacallits.  ;-)

I mention this for context: my generic perception of virtualenv is that
it's a fancy version of PYTHONHOME for people who can't install to
site-packages and for some reason don't just dump their files in a
PYTHONPATH directory like all those complaining people obviously did.  ;-)


 All I know (and care) is
> that it promises to do all that stuff for me, and without affecting the
> general public (ie, the distro-provided Python apps).
>
> And that's why I think the width of pages containing flowed text
> should be left up to the user to configure.
>

Your analogy is backwards: virtualenv is a generic, does-it-all-for-you, no
need to touch it solution.  User CSS and window sizes have to specified
per-site.  (Note that it doesn't suffice to use a small window to get
optimal wrap width: you have to resize to allow for navigation bars,
multiple columns, etc.)

I think we should just agree to disagree; there's virtually no way I'm
going to be convinced on either of these points.

(I do, however, remain open to learning something new about virtualenv, if
it actually does something besides make it possible for you to deal with
ill-behaved setup scripts and installation tools that won't just let you
point

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Victor Stinner 

On 27/03/2012 20:18, Matt Joiner wrote:

Also monotonic should either not exist if it's not available, or always
guarantee a (artificially) monotonic value.


What do you mean by "(artificially) monotonic value"? Should Python 
workaround OS bugs by always returning the maximum value of the clock?



Finding out that something
is already known to not work shouldn't require a call and a faked OSError.


What do you mean? time.monotonic() is not implemented if the OS doesn't 
provide any monotonic clock (e.g. if clock_gettime(CLOCK_MONOTONIC) is 
missing on UNIX). OSError is only raised when the OS returns an error. 
There is no such "faked OSError".


Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Bug tracker outage

2012-03-27 Thread 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'll notify here when the upgrade
is complete.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Approve PEP 411.

2012-03-27 Thread Victor Stinner 
2012/3/27 guido.van.rossum :
> http://hg.python.org/peps/rev/b9f43fe69691
> changeset:   4152:b9f43fe69691
> user:        Guido van Rossum 
> date:        Mon Mar 26 20:35:14 2012 -0700
> summary:
>  Approve PEP 411.
> (...)
> -Status: Draft
> +Status: Approved

The pep0 module doesn't accept the "Approved" status. I suppose that
you mean "Accepted" and so changed the status. If not, please revert
my change and fix the pep0 module.

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Nick Coghlan 
Matt, we need the fallback behaviour in the stdlib so we can gracefully
degrade the stdlib's *own* timeout handling back to the 3.2 status quo when
there is no monotic clock available. It is *not* acceptable for the Python
3.3 stdlib to only work on platforms that provide a monotonic clock.

Since duplicating that logic in every module that handles timeouts would be
silly, it makes sense to provide an obvious way to do it in the time
module.

--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Victor Stinner 

Scott wrote:

<< The Boost implementation can be summarized as:

system_clock:

 mac = gettimeofday
 posix = clock_gettime(CLOCK_REALTIME)
 win = GetSystemTimeAsFileTime

steady_clock:

 mac = mach_absolute_time
 posix = clock_gettime(CLOCK_MONOTONIC)
 win = QueryPerformanceCounter

high_resolution_clock:

 * = { steady_clock, if available
   system_clock, otherwise } >>

I read again the doc of the QElapsedTimer class of the Qt library. So Qt 
and Boost agree to say that QueryPerformanceCounter() *is* monotonic.


I was confused because of a bug found in 2006 in Windows XP on multicore 
processors. QueryPerformanceCounter() gave a different value on each 
core. The bug was fixed in Windows and is known as KB896256 (I already 
added a link to the bug in the PEP).



I added a time.hires() clock to the PEP for the benchmarking/profiling
use case (...)


It is this always-having-to-manually-fallback-depending-on-os that I was
hoping your new functionality would avoid. Is time.try_monotonic()
suitable for this usecase?


If QueryPerformanceCounter() is monotonic, the API can be simplified to:

 * 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()".


--

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


I don't know if other clocks used by my time.monotonic() proposition can 
be adjusted or not.


If I understand correctly, time.steady() cannot be implemented using 
CLOCK_MONOTONIC on Linux because CLOCK_MONOTONIC can be adjusted?


Does it really matter if a monotonic speed is adjusted?

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] OT: single directory development [was Re: Playing with a new theme for the docs]

2012-03-27 Thread Ethan Furman 

PJ Eby wrote:
Really?  I've been doing "dump the app in a directory" since 1998 or so 
on various *nix platforms.  And when distutils came along, I set up a 
user-specific cfg to install in the same directory.  ISTR a 5-line 
pydistutils.cfg is sufficient to make everything go into to a particular 
directory, for packages using distutils for installation.


Perhaps somebody could clue me in on the best way to handle this scenario:

I develop in a single directory:

c:\source\loom\
loom.py
test_loom.py

because test_loom could at some point be executed by somebody besides 
me, while living in site-packages, I have test_loom.py create its needed 
files, including dynamic test scripts, in a temp directory.  While this 
works fine for site-packages, it doesn't work at all while testing as 
the test script, being somewhere else, won't be able to load my test 
copy of loom.


I know I have at least two choices:
  - go with a virtualenv and have my development code be in the
virtualenv site-packages
  - insert the current path into sys.path before calling out to
the dynamic scripts, but only if the current path is not
site-packages

Suggestions?

~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Matt Joiner 
On Mar 28, 2012 8:38 AM, "Victor Stinner"  wrote:
>
> Scott wrote:
>
> << The Boost implementation can be summarized as:
>
> system_clock:
>
>  mac = gettimeofday
>  posix = clock_gettime(CLOCK_REALTIME)
>  win = GetSystemTimeAsFileTime
>
> steady_clock:
>
>  mac = mach_absolute_time
>  posix = clock_gettime(CLOCK_MONOTONIC)
>  win = QueryPerformanceCounter
>
> high_resolution_clock:
>
>  * = { steady_clock, if available
>   system_clock, otherwise } >>
>
> I read again the doc of the QElapsedTimer class of the Qt library. So Qt
and Boost agree to say that QueryPerformanceCounter() *is* monotonic.
>
> I was confused because of a bug found in 2006 in Windows XP on multicore
processors. QueryPerformanceCounter() gave a different value on each core.
The bug was fixed in Windows and is known as KB896256 (I already added a
link to the bug in the PEP).
>
>>> I added a time.hires() clock to the PEP for the benchmarking/profiling
>>> use case (...)
>>
>>
>> It is this always-having-to-manually-fallback-depending-on-os that I was
>> hoping your new functionality would avoid. Is time.try_monotonic()
>> suitable for this usecase?
>
>
> If QueryPerformanceCounter() is monotonic, the API can be simplified to:
>
>  * 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()".
>
> --
>
> 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.28.

Monotonic. It's still monotonic if it is adjusted forward, and that's okay.

>
> I don't know if other clocks used by my time.monotonic() proposition can
be adjusted or not.
>
> If I understand correctly, time.steady() cannot be implemented using
CLOCK_MONOTONIC on Linux because CLOCK_MONOTONIC can be adjusted?
>
> Does it really matter if a monotonic speed is adjusted?
>
>
> Victor
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Playing with a new theme for the docs

2012-03-27 Thread Stephen J. Turnbull 
On Wed, Mar 28, 2012 at 4:45 AM, PJ Eby  wrote:

> [ body { width: 65em; } ] won't work - it'll make the entire page
> that width, instead of just text paragraphs.

True (I realized that might be bad in many cases later -- should have
tested first rather than posting something  random), but despite your
argument, "p { max-width: 40em; }" will be good
enough to handle pages where the designer leaves text width up to the
user.  Pages (or parts thereof) where the designer fubars the format
for you are not my problem, they're *your* problem.  "Be careful what
you ask for, because you just might get it."

Also, this is UI, in an environment where poor UI is easily worked
around with a flick of your mouse.  A improvement in 90% of the cases
is a 90% improvement -- there won't be any fatal problems in the 10%
where designers choose a max-width that's 200% of your personal
max-width or whatever.

> Your analogy is backwards: virtualenv is a generic,
> does-it-all-for-you, no need to touch it solution.

If you want to phrase it as an analogy, mine is

virtualenv :: do-it-*for*-you :: site-specified max-width

but

dump-it-in-a-directory :: DIY :: user-specified CSS.

The point of the analogy is that you're being inconsistent by using
dump-it-in-a-directory yourself but recommending site-specified
max-width for the Python docs.

It's true I'm being similarly inconsistent in a sense (using
virtualenv myself but recommending user CSS for Python docs).
However, in this discussion, there are more important things than
consistency.  I think there are an awful lot of people who need
reliable deployment, consistent with their development environments,
so it makes sense to have Ian package it up for us as "virtualenv",
and for it to be somewhat inflexible in its rules for doing so.  OTOH,
AFAICS those who use maximized windows for everything are a relatively
small minority who will be well-served by a simple workaround, and
there are gains to having the flexibility for the rest of us.

The big problem from my point of view with the user CSS "solution" to
the maximized-window problem is that common browsers don't make this
easy to do.  Cf. Terry Reedy's post
asking how to specify user CSS for Firefox (where it's actually easy
enough to do once you know how, but evidently not very discoverable).
However, if you're in a sufficiently small minority (as I believe you
are), it makes sense for Georg to (regretfully) ask you to use
personal CSS to tell your browser about your preference.

> User CSS and window sizes have to specified per-site.

They do?  But *you* don't, you just maximize your window.  So only a
few sites will need specification in any case, those whose max-width
exceeds tolerable bounds for you.  And a personal max-width will
affect only unbounded pages unless you use "! important".

The point of user CSS is not to get optimality, which is a
content-dependent problem for negotiation between user and designer,
and sometimes one side or the other takes absolute priority.  It's to
ensure that users with special needs (very nearsighted users, users
who prefer to work always in a maximized browser window) don't get
screwed by extreme designs.

> (Note that it doesn't suffice to use a small
> window to get optimal wrap width:

I don't believe in optimal wrap width, and as far as I know, neither
do the 1% of designers.  I don't even *have* a personal optimal wrap
width, although max height is almost always close enough to optimal.
But I sometimes maximize the width of my browser window to get even
more of the "structure" of text viewable in it, or reduce it to make
word-for-word reading more efficient.

Again, the problem here is not "suboptimal".  AFAICS, it's preventing
a few people who have evolved personal workflows adapted to a common
design pattern that's not appropriate for documentation (IMO YMMV)
from getting *pessimal* results.  I believe that you can get what you
need with user CSS in the case of no max-width (let's not forget that
you and R. David Murray may prefer different values!), while many
use-cases would want no max-width.  But "p { max-width: none !
important; }" would not work well for us, since it would override all
designers who set max-width.

> I think we should just agree to disagree; there's virtually
> no way I'm going to be convinced on either of these points.

Hey, I'm an economist: de gustibus non est disputandum.

Convincing you is not my goal; I want to convince Georg!  *Policy*
needs to be for the greatest good of the greatest number, and Georg
IMO should set max-width, or not, as that makes reading the
documentation more effective for the most people.  I prefer "not",
assuming it doesn't completely trash its usability for you and David
(and assuming you're in as small a minority as I believe you to be).
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Nick Coghlan 
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 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 fallback version "hires" as it suggests it may
be higher resolution than time.time() and that's completely the wrong
idea. 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), then we're back to being able to
enforce monotonicity even if the underlying clock jumps backwards due
to system clock adjustments.

Specifically:

time.time() = system clock
time._monotonic() = system level monotonic clock (if it exists)

time.monotonic() = clock based on either time._monotonic() (if
available) or time.time() (if not) that enforces monotonicity of
returned values.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OT: single directory development [was Re: Playing with a new theme for the docs]

2012-03-27 Thread PJ Eby 
On Tue, Mar 27, 2012 at 9:02 PM, Ethan Furman  wrote:

> PJ Eby wrote:
>
>> Really?  I've been doing "dump the app in a directory" since 1998 or so
>> on various *nix platforms.  And when distutils came along, I set up a
>> user-specific cfg to install in the same directory.  ISTR a 5-line
>> pydistutils.cfg is sufficient to make everything go into to a particular
>> directory, for packages using distutils for installation.
>>
>
> Perhaps somebody could clue me in on the best way to handle this scenario:
>
> I develop in a single directory:
>
>c:\source\loom\
>loom.py
>test_loom.py
>
> because test_loom could at some point be executed by somebody besides me,
> while living in site-packages, I have test_loom.py create its needed files,
> including dynamic test scripts, in a temp directory.  While this works fine
> for site-packages, it doesn't work at all while testing as the test script,
> being somewhere else, won't be able to load my test copy of loom.
>
> I know I have at least two choices:
>  - go with a virtualenv and have my development code be in the
>virtualenv site-packages
>  - insert the current path into sys.path before calling out to
>the dynamic scripts, but only if the current path is not
>site-packages
>
> Suggestions?
>

At first I didn't understand the question, because I was misled by your
directory layout sketch -- AFAICT it's completely irrelevant to the real
problem, which is simply making sure that the directory containing
loom.__file__ is on sys.path.  I'm somewhat hard-pressed to see, "embed the
virtualenv tool in my test script" as superior to either "Copy the modules
I want to the temp directory alongside the modules" or "setup sys.path when
running the scripts" (e.g. by altering the PYTHONPATH in the child
environment).

(I'm not clear on why you want to skip the path alteration in the
site-packages case - is there something else in site-packages you don't
want having top import priority?  And if not, why not?)

All that being said, I can see why under certain circumstances, a
virtualenv might be an optimal tool to reach for; it's just not the *first*
thing I'd reach for if a sys.path[0] assignment or environment variable
setting would suffice to get the needed module(s) on the path.





> ~Ethan~
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Scott Dial 
On 3/27/2012 8:36 PM, Victor Stinner wrote:
> Scott 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 can be adjusted by NTP, at least on Linux
> < 2.6.28.
> 
> I don't know if other clocks used by my time.monotonic() proposition can
> be adjusted or not.
> 
> If I understand correctly, time.steady() cannot be implemented using
> CLOCK_MONOTONIC on Linux because CLOCK_MONOTONIC can be adjusted?
> 
> Does it really matter if a monotonic speed is adjusted?

You are right that CLOCK_MONOTONIC can be adjusted, so the Boost
implementation is wrong. I'm not sure that CLOCK_MONOTONIC_RAW is right
either due to suspend -- there doesn't appear to be a POSIX or Linux
clock that is defined that meets the "steady" definition.

I am not familiar enough with Windows or Mac to know for certain whether
the Boost implementation has the correct behaviors either.

With that in mind, it's certainly better that we just provide
time.monotonic() for now. If platform support becomes available, then we
can expose that as it becomes available in the future. In other words,
at this time, I don't think "time.steady()" can be implemented
faithfully for any platform so lets just not have it at all.

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. I can't imagine a scenario where you would ask for a
monotonic clock and would rather have an error than have Python fill in
the gap with an emulation.

-- 
Scott Dial
[email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418: Add monotonic clock

2012-03-27 Thread Georg Brandl 
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 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 fallback version "hires" as it suggests it may
> be higher resolution than time.time() and that's completely the wrong
> idea.

It's also a completely ugly name, since it's quite hard to figure out
what it is supposed to stand for in the first place.

Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com