Re: [Python-Dev] cpython: Adding unittest.mock documentation

2012-03-26 Thread Georg Brandl
On 26.03.2012 00:13, michael.foord wrote:
> http://hg.python.org/cpython/rev/adc1fc2dc872
> changeset:   75938:adc1fc2dc872
> user:Michael Foord 
> date:Sun Mar 25 23:12:55 2012 +0100
> summary:
>   Adding unittest.mock documentation
> 
> files:
>   Doc/library/development.rst   |6 +
>   Doc/library/unittest.mock-examples.rst|  887 +
>   Doc/library/unittest.mock-getting-started.rst |  419 
>   Doc/library/unittest.mock-helpers.rst |  537 +
>   Doc/library/unittest.mock-magicmethods.rst|  226 ++
>   Doc/library/unittest.mock-patch.rst   |  538 +
>   Doc/library/unittest.mock.rst |  900 ++
>   Lib/unittest/mock.py  |8 +-
>   8 files changed, 3516 insertions(+), 5 deletions(-)

That seems a bit much splitting to me.

(By the way, the ".. module::" directive should only be in *one* place.)

I would organize the mock, mock-patch, mock-magicmethods and mock-helpers as one
file in Doc/library, and put the other two in Doc/howto, just as for logging.

In general, I wouldn't mind splitting off more of the exemplary material from
the main library docs, putting it in the howto section.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Scott Dial
On 3/26/2012 1:00 AM, Greg Ewing wrote:
> This seems to be another case of the designer over-specifying
> things. The page should just specify a sans-serif font and let
> the browser choose the best one available. Or not specify
> a font at all and leave it up to the user whether he wants
> serif or sans-serif for the body text -- some people have
> already said here that they prefer serif.

Why even bother formatting the page?

The authorship and editorship have authority to dictate the presentation
of the content. A large part of the effectiveness of a document and it's
ease of consumption is determined by how it appears in whatever medium
it's delivered on. While this particular medium invites the readership
to participate in design choices, fonts are not all created equal and
practical matters (size, tracking, and kerning) will dictate that some
fonts will present better than other fonts. Consistent presentation
across different systems is also a virtue, since people develop
familiarity with the presentation and find information more readily if
the presentation is consistent.

I have no problem having Georg dictating to me the best font with which
to present the documentation. However, I'd appreciate fallback choices
that are of a similar appearance along the way to the ultimate fallback
of "sans-serif". Practically, the fonts available are unknown and unless
we adopt the use of a liberally licensed OpenType font and use
@font-face to embed a font, we need to provide fallbacks.

-- 
Scott Dial
sc...@scottdial.com
___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Zvezdan Petkovic

On Mar 26, 2012, at 12:22 AM, Terry Reedy wrote:

> Does the css specify Courier New or is this an unfortunate fallback that 
> might be improved? Perhaps things look better on max/*nix?

I just checked pydoctheme.css and Courier New is not specified there.
It only specifies monospace.

That's a default monospace font set in your browser.
I see the code rendered in the font I selected in my browser preferences as 
Fixed-width font: Menlo 14pt.  It's not thin at all -- that's why I selected 
it.  :-)

It seems you may want to change that setting in your browser.
Firefox uses Courier New as a default setting.

Zvezdan

___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Matt Joiner
the text in the nav bar is too small, particularly in the search box.
___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread R. David Murray
On Mon, 26 Mar 2012 08:44:40 -0400, Scott Dial  
wrote:
> Why even bother formatting the page?

The web started out as *content markup*.  Functional declarations, not
style declarations.  I wish it had stayed that way, but it was inevitable
that it would not.

> The authorship and editorship have authority to dictate the presentation
> of the content. A large part of the effectiveness of a document and it's
> ease of consumption is determined by how it appears in whatever medium
> it's delivered on. While this particular medium invites the readership

This argument can get as bad as editor religious wars.  I like sites
that do more content markup and less styling.  You like the reverse.

There is a good reason to separate css (style) from markup.  I just
wish browsers gave easier control over the css, and that more designers
would stay concious of how a page *reads* (ie: access to the content)
without the css (and javascript).

I think Georg's design does pretty well in that last regard.  (Except for
those darn paragraph characters after the headers, but that flaw was
in the old design too.  Oh, and it would be even better, IMO, if the
top navigation block wasn't there when there's no CSS, but that's more
of an issue for easier access from screen readers, since the block is
reasonably short).

--David
___
Python-Dev mailing list
Python-Dev@python.org
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 install layout and the PATH on win32

2012-03-26 Thread VanL
I heard back from Enthought on this part of the proposal. They could 
accommodate this change.


1) The layout for the python root directory for all platforms should be
as follows:

stdlib = {base/userbase}/lib/
platstdlib = {base/userbase}/lib/
purelib = {base/userbase}/lib/site-packages
platlib = {base/userbase}/lib/site-packages
include = {base/userbase}/include/python{py_version_short}
scripts = {base/userbase}/bin
data = {base/userbase}
___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Terry Reedy

On 3/26/2012 8:46 AM, Zvezdan Petkovic wrote:


On Mar 26, 2012, at 12:22 AM, Terry Reedy wrote:


Does the css specify Courier New or is this an unfortunate fallback
that might be improved? Perhaps things look better on max/*nix?


I just checked pydoctheme.css and Courier New is not specified
there. It only specifies monospace.

That's a default monospace font set in your browser. I see the code
rendered in the font I selected in my browser preferences as
Fixed-width font: Menlo 14pt.  It's not thin at all -- that's why I
selected it.  :-)

It seems you may want to change that setting in your browser. Firefox
uses Courier New as a default setting.


I found the FireFox monospace setting under
Tools / Options / Content / Default font: / Advanced
and switched to Deja Vu mono, that being the first obviously monospace 
font I saw. (Lucida Console is similar.) It has the same 2-pixel lines 
as Ariel, and the page now looks okay, although when black (as for 
False, True),the lack of serifs reduces the contrast with Arial. I am 
guessing that the page now looks somewhat more like it did for Georg 
when he worked on it.


Windows Help uses Internet Explorer settings.
Options / Internet Options / General / Appearance / Fonts
However, this only allows choice of base font for pages without a 
specified text font, so I do know know what will happen when new format 
is applied to the .chm files.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread PJ Eby
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.  Calling this a "special" way of invoking Python is disingenuous
at best: it's the documented *default* way of deploying and invoking a
Python script with accompanying libraries.

In contrast, the directory layout thread is about supporting virtualenvs,
which aren't even *in* Python yet -- if anything is to be considered a
special case, that would be it.

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.
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Andrea Crotti

On 03/24/2012 03:30 AM, PJ Eby wrote:



Weird - I have the exact *opposite* problem, where I have to resize my 
window because somebody *didn't* set their text max-width sanely (to a 
reasonable value based on ems instead of pixels), and I have nearly 
1920 pixels of raw text spanning my screen.  Bloody impossible to read 
that way.


But I guess this is going to turn into one of those vi vs. emacs holy 
war things...


(Personally, I prefer jEdit, or nano if absolutely forced to edit in a 
terminal. Heretical, I know.  To the comfy chair with me!)





Suppose the author set the size to 1000 pixels, you would end up with 
920 white pixels on the side,

does it make sense?

Using a tiling window manager (for example awesome or xmonad) would 
solve your problem in a more definitive way imho

than hoping in the web designer choices..
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread PJ Eby
On Sat, Mar 24, 2012 at 8:41 PM, Ben Finney wrote:

> PJ Eby  writes:
>
> > On Sat, Mar 24, 2012 at 1:32 AM, Greg Ewing  >wrote:
> >
> > > If you don't want 1920-pixel-wide text, why make your browser window
> > > that large?
> >
> > Not every tab in my browser is text for reading; some are apps that
> > need the extra horizontal space.
>
> So, again, why make your browser window *for reading text* that large?
>

Because I have one browser window, and it's maximized.  And I can do this,
because most websites are designed in such a way that they have usable
margins for text flows.  Even PEPs and Python mailing list archives, for
example, have sane text margins -- shall we go back and make *those*
dependent on window width instead?

Also, looking at the email I got from you, it has sane text margins in it.
 If you don't believe in text margins, why are you using a client that
wraps lines and thereby prevents me from viewing your email with
full-screen-width text?  ;-)

(In fairness, I am using a client that *doesn't* wrap the lines, AFAICT.
 But if Gmail had such an option I would probably use it if I knew where it
was in the vast assortment of settings.  Which ties in nicely with my next
point, below...)


Everyone has different needs for how large the text should be and how
> much of it should go across the window. Every one of us is in a minority
> when it comes to those needs; that's exactly what a configuration
> setting is good for.
>

Designers' rules of thumb for text width are based on empirical
observations of focal length, saccades, etc.  If you have special needs
visually, you're more likely to require the text read to you, than to have
narrower text, and I at least am unable to conceive of a visual disability
that would be helped by *increasing* the text width.

In other words, there is a well-established *majority* need for how many
characters should appear in an unwrapped line of text, based on majority
physiology.  Designers who limit it based on pixel size are Doing It Wrong;
the max width should be based on em's rather than pixels. (Font sizes are a
separate issue.)

Done correctly (as visible, say, on any plaintext PEP), you may resize the
window and change the font size to your heart's content without affecting
the text width in characters.

(Also, as a side note: adding lots of configuration options to an interface
design is what adding lots of code is to a software design: a smell that
the designer isn't *designing* enough.)
___
Python-Dev mailing list
Python-Dev@python.org
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 install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

2012-03-26 Thread Carl Meyer
On 03/23/2012 09:22 PM, PJ Eby wrote:
> On Mar 23, 2012 3:53 PM, "Carl Meyer" > On 03/23/2012 12:35 PM, PJ Eby wrote:
>> > AFAICT, virtualenvs are overkill for most development anyway.  If you're
>> > not using distutils except to install dependencies, then configure
>> > distutils to install scripts and libraries to the same directory, and
>> > then do all your development in that directory.  Presto!  You now have a
>> > cross-platform "virtualenv".  Want the scripts on your path?  Add that
>> > directory to your path... or if on Windows, don't bother, since the
>> > current directory is usually on the path.   (In fact, if you're only
>> > using easy_install to install your dependencies, you don't even need to
>> > edit the distutils configuration, just use "-md targetdir".)
>>
>> Creating and using a virtualenv is, in practice, _easier_ than any of
>> those alternatives,
> 
> Really?  As I said, I've never seen the need to try, since just
> installing stuff to a directory on PYTHONPATH seems quite easy enough
> for me.
> 
>> that the "isolation from system site-packages" feature is quite popular
>> (the outpouring of gratitude when virtualenv went isolated-by-default a
>> few months ago was astonishing), and AFAIK none of your alternative
>> proposals support that at all.
> 
> What is this isolation for, exactly?  If you don't want site-packages on
> your path, why not use python -S?
> 
> (Sure, nobody knows about these things, but surely that's a
> documentation problem, not a tooling problem.)
> 
> Don't get me wrong, I don't have any deep objection to virtualenvs, I've
> just never seen the *point* (outside of the scenarios I mentioned),

No problem. I was just responding to the assertion that people only use
virtualenvs because they aren't aware of the alternatives, which I don't
believe is true. It's likely many people aren't aware of python -S, or
of everything that's possible via distutils.cfg. But even if they were,
for the cases where I commonly see virtualenv in use, it solves the same
problems more easily and with much less fiddling with config files and
environment variables.

Case in point: libraries that also install scripts for use in
development or build processes. If you're DIY, you have to figure out
where to put these, too, and make sure it's on your PATH. And if you
want isolation, not only do you have to remember to run python -S every
time, you also have to edit every script wrapper to put -S in the
shebang line. With virtualenv+easy_install/pip, all of these things Just
Simply Work, and (mostly) in an intuitive way. That's why people use it.

> thus don't see what great advantage will be had by rearranging layouts
> to make them shareable across platforms, when "throw stuff in a
> directory" seems perfectly serviceable for that use case already.  Tools
> that *don't* support "just throw it in a directory" as a deployment
> option are IMO unpythonic -- practicality beats purity, after all.  ;-)

No disagreement here. I think virtualenv's sweet spot is as a convenient
tool for development environments (used in virtualenvwrapper fashion,
where the file structure of the virtualenv itself is hidden away and you
never see it at all). I think it's fine to deploy _into_ a virtualenv,
if you find that convenient too (though I think there are real
advantages to deploying just a big ball of code with no need for
installers). But I see little reason to make virtualenvs relocatable or
sharable across platforms. I don't think virtualenvs as on on-disk file
structure make a good distribution/deployment mechanism at all.

IOW, I hijacked this thread (sorry) to respond to a specific denigration
of the value of virtualenv that I disagree with. I don't care about
making virtualenvs consistent across platforms.

Carl



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread R. David Murray
On Mon, 26 Mar 2012 12:55:42 -0400, PJ Eby  wrote:
> On Sat, Mar 24, 2012 at 8:41 PM, Ben Finney wrote:
> > So, again, why make your browser window *for reading text* that large?
> 
> Because I have one browser window, and it's maximized.  And I can do this,
> because most websites are designed in such a way that they have usable
> margins for text flows.  Even PEPs and Python mailing list archives, for
> example, have sane text margins -- shall we go back and make *those*
> dependent on window width instead?
>
[...]
>
> Designers' rules of thumb for text width are based on empirical
> observations of focal length, saccades, etc.  If you have special needs
> visually, you're more likely to require the text read to you, than to have
> narrower text, and I at least am unable to conceive of a visual disability
> that would be helped by *increasing* the text width.
> 
> In other words, there is a well-established *majority* need for how many
> characters should appear in an unwrapped line of text, based on majority
> physiology.  Designers who limit it based on pixel size are Doing It Wrong;
> the max width should be based on em's rather than pixels. (Font sizes are a
> separate issue.)

I'm with Philip on this one.  I hate web sites that have a fixed text
width (so that you can't resize narrower and still read it), but I also
prefer ones that set the max width to the "readable size" in number of
character positions.

Like Philip, I have *one* window.  My window manager (ratpoison) is more
like 'screen' for X: you *can* split the window up, but it is *much* more
useful to have only one window visible at a time, most of the time.  So
splitting the window in order to make the text narrow enough to read
slows down my workflow.  (Which means that on the python docs and
the bug tracker I just put up with reading it wide...)

I realize that I'm in the minority, though :)

--David
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Glenn Linderman

On 3/26/2012 10:19 AM, R. David Murray wrote:

Like Philip, I have*one*  window.  My window manager (ratpoison) is more
like 'screen' for X: you*can*  split the window up, but it is*much*  more
useful to have only one window visible at a time, most of the time.


I'm amazed at the number of people that use maximized windows, one 
application at a time.  I have 2 1600x1200 displays, with 10-30 
overlapping windows partially visible, and sometimes wish I had 3 
displays, so I could see more windows at a time... but then I'd have to 
turn my head more, so maybe this is optimal.  Two displays lets me get 
my autohidden taskbar in the vertical center, for quick access from 
either side.


I occasionally maximize a window on one screen or the other (one 
portrait, one landscape mode), mostly for picture viewing, but a few 
other times as well.



I realize that I'm in the minority, though


No doubt I am too :)  Everyone is a minority, when all idiotsyncrasies 
[sic] are considered!
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Ethan Furman

Glenn Linderman wrote:

  On 3/26/2012 10:19 AM, R. David Murray wrote:

Like Philip, I have *one* window.  My window manager (ratpoison) is more
like 'screen' for X: you *can* split the window up, but it is *much* more
useful to have only one window visible at a time, most of the time.


I'm amazed at the number of people that use maximized windows, one 
application at a time.  I have 2 1600x1200 displays, with 10-30 
overlapping windows partially visible, and sometimes wish I had 3 
displays, so I could see more windows at a time... but then I'd have to 
turn my head more, so maybe this is optimal.  Two displays lets me get 
my autohidden taskbar in the vertical center, for quick access from 
either side.


I also have two monitors, I use goScreen for three virtual desktops (I'm 
stuck with XP -- which is to say MS), and each application I use is 
full-screen while I'm using it.  I find windows that I'm not using at 
that moment a distraction.


~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Ethan Furman

Georg Brandl wrote:

On 25.03.2012 21:11, Steven D'Aprano wrote:

Georg Brandl wrote:


Thanks everyone for the overwhelmingly positive feedback.  I've committed the
new design to 3.2 and 3.3 for now, and it will be live for the 3.3 docs
momentarily (3.2 isn't rebuilt at the moment until 3.2.3 final goes out).
I'll transplant to 2.7 too, probably after the final release of 2.7.3.
I think it would be better to leave 2.7 with the old theme, to keep it 
visually distinct from the nifty new theme used with the nifty new 3.2 and 3.3 
versions.


Hmm, -0 here.  I'd like more opinions on this from other devs.


+1 on keeping the 2.x and 3.x styles separate.

~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Ethan Furman

Georg Brandl wrote:

Here's another try, mainly with default browser font size, more contrast and
collapsible sidebar again:

http://www.python.org/~gbrandl/build/html2/

I've also added a little questionable gimmick to the sidebar (when you collapse
it and expand it again, the content is shown at your current scroll location).

Have fun!
Georg



Looks great!  Thanks!

~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Glenn Linderman

On 3/26/2012 10:58 AM, Ethan Furman wrote:

Glenn Linderman wrote:

  On 3/26/2012 10:19 AM, R. David Murray wrote:
Like Philip, I have *one* window.  My window manager (ratpoison) is 
more
like 'screen' for X: you *can* split the window up, but it is *much* 
more

useful to have only one window visible at a time, most of the time.


I'm amazed at the number of people that use maximized windows, one 
application at a time.  I have 2 1600x1200 displays, with 10-30 
overlapping windows partially visible, and sometimes wish I had 3 
displays, so I could see more windows at a time... but then I'd have 
to turn my head more, so maybe this is optimal.  Two displays lets me 
get my autohidden taskbar in the vertical center, for quick access 
from either side.


I also have two monitors, I use goScreen for three virtual desktops 
(I'm stuck with XP -- which is to say MS), and each application I use 
is full-screen while I'm using it.  I find windows that I'm not using 
at that moment a distraction. 


Interesting.  I guess I'm always distracted :)  But I often need data or 
information from multiple applications in order to make progress on a 
project... which is why each application seldom gets maximized.  I even 
use multiple Firefox profiles concurrently, to have multiple browsers 
open for different purposes, as well as multiple tabs within each of 
them. Sometimes I even need multiple instances of Emacs, as well as 
multiple windows for a single instance, but that is usually very 
temporary, due to an interruption (distraction).


So my pet peeve about web sites is those that, although they seem to 
dynamically adjust to different monitor sizes, seem to miscalculate, and 
display a horizontal scroll bar, and consistently chop stuff off on the 
right edge of my non-maximized window.
___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Antoine Pitrou
On Mon, 26 Mar 2012 12:25:20 -0700
Ethan Furman  wrote:
> Georg Brandl wrote:
> > On 25.03.2012 21:11, Steven D'Aprano wrote:
> >> Georg Brandl wrote:
> >>
> >>> Thanks everyone for the overwhelmingly positive feedback.  I've committed 
> >>> the
> >>> new design to 3.2 and 3.3 for now, and it will be live for the 3.3 docs
> >>> momentarily (3.2 isn't rebuilt at the moment until 3.2.3 final goes out).
> >>> I'll transplant to 2.7 too, probably after the final release of 2.7.3.
> >> I think it would be better to leave 2.7 with the old theme, to keep it 
> >> visually distinct from the nifty new theme used with the nifty new 3.2 and 
> >> 3.3 
> >> versions.
> > 
> > Hmm, -0 here.  I'd like more opinions on this from other devs.
> 
> +1 on keeping the 2.x and 3.x styles separate.

I don't really understand the point. If we want to distinguish between
2.x and 3.x, perhaps a lighter difference would suffice.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
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 install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

2012-03-26 Thread PJ Eby
On Mon, Mar 26, 2012 at 12:58 PM, Carl Meyer  wrote:

> No disagreement here. I think virtualenv's sweet spot is as a convenient
> tool for development environments (used in virtualenvwrapper fashion,
> where the file structure of the virtualenv itself is hidden away and you
> never see it at all). I think it's fine to deploy _into_ a virtualenv,
> if you find that convenient too (though I think there are real
> advantages to deploying just a big ball of code with no need for
> installers). But I see little reason to make virtualenvs relocatable or
> sharable across platforms. I don't think virtualenvs as on on-disk file
> structure make a good distribution/deployment mechanism at all.
>
> IOW, I hijacked this thread (sorry) to respond to a specific denigration
> of the value of virtualenv that I disagree with. I don't care about
> making virtualenvs consistent across platforms.
>

Well, if you're the virtualenv maintainer (or at least the PEP author), and
you're basically shooting down the principal rationale for reorganizing the
Windows directory layout, then it's not really much of a hijack - it's
pretty darn central to the thread!
___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Ethan Furman

Antoine Pitrou wrote:

On Mon, 26 Mar 2012 12:25:20 -0700
Ethan Furman  wrote:

Georg Brandl wrote:

On 25.03.2012 21:11, Steven D'Aprano wrote:

Georg Brandl wrote:


Thanks everyone for the overwhelmingly positive feedback.  I've committed the
new design to 3.2 and 3.3 for now, and it will be live for the 3.3 docs
momentarily (3.2 isn't rebuilt at the moment until 3.2.3 final goes out).
I'll transplant to 2.7 too, probably after the final release of 2.7.3.
I think it would be better to leave 2.7 with the old theme, to keep it 
visually distinct from the nifty new theme used with the nifty new 3.2 and 3.3 
versions.

Hmm, -0 here.  I'd like more opinions on this from other devs.

+1 on keeping the 2.x and 3.x styles separate.


I don't really understand the point. If we want to distinguish between
2.x and 3.x, perhaps a lighter difference would suffice.


The point being that 2.x is finished, and the bulk of our effort is now 
on 3.x.  By not changing the 2.x docs we are emphasizing that 3.x is the 
way to go.


~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Ethan Furman

Antoine Pitrou wrote:

On Sun, 25 Mar 2012 08:34:44 +0200
Also I think there should be some jquery animation when
collapsing/expanding.


Please, no.  I don't need my technical web pages singing and dancing for 
me.  ;)


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


Re: [Python-Dev] cpython: Adding unittest.mock documentation

2012-03-26 Thread Michael Foord

On 26 Mar 2012, at 08:11, Georg Brandl wrote:

> On 26.03.2012 00:13, michael.foord wrote:
>> http://hg.python.org/cpython/rev/adc1fc2dc872
>> changeset:   75938:adc1fc2dc872
>> user:Michael Foord 
>> date:Sun Mar 25 23:12:55 2012 +0100
>> summary:
>>  Adding unittest.mock documentation
>> 
>> files:
>>  Doc/library/development.rst   |6 +
>>  Doc/library/unittest.mock-examples.rst|  887 +
>>  Doc/library/unittest.mock-getting-started.rst |  419 
>>  Doc/library/unittest.mock-helpers.rst |  537 +
>>  Doc/library/unittest.mock-magicmethods.rst|  226 ++
>>  Doc/library/unittest.mock-patch.rst   |  538 +
>>  Doc/library/unittest.mock.rst |  900 ++
>>  Lib/unittest/mock.py  |8 +-
>>  8 files changed, 3516 insertions(+), 5 deletions(-)
> 
> That seems a bit much splitting to me.

Ok, it's just the style of the current mock documentation. My original 
intention *was* to create one big-ass api doc more in keeping with the current 
library doc styles.

> 
> (By the way, the ".. module::" directive should only be in *one* place.)

Thanks. Maybe sphinx could complain about duplicates.

> 
> I would organize the mock, mock-patch, mock-magicmethods and mock-helpers as 
> one
> file in Doc/library, and put the other two in Doc/howto, just as for logging.
> 


The examples pages aren't written in a howto style - there's a getting started 
guide (basic examples) and then a bunch of separate more advanced examples 
illustrating specific features of unittest.mock or particular mocking scenarios.

I'll move the api documentation into a single doc and the getting started guide 
and examples as a second page.

> In general, I wouldn't mind splitting off more of the exemplary material from
> the main library docs, putting it in the howto section.

Hmmm... in general I think I'd like to see the documentation for non-trivial 
modules include some examples (separate from - and after - the api docs) . 
Hiving them off as a howto makes them harder to find. More in depth howto 
guides in addition to this are a good thing though.

Michael

> 
> Georg
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> 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
Python-Dev@python.org
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 install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

2012-03-26 Thread Glenn Linderman

On 3/26/2012 12:27 PM, PJ Eby wrote:
On Mon, Mar 26, 2012 at 12:58 PM, Carl Meyer > wrote:


No disagreement here. I think virtualenv's sweet spot is as a
convenient
tool for development environments (used in virtualenvwrapper fashion,
where the file structure of the virtualenv itself is hidden away
and you
never see it at all). I think it's fine to deploy _into_ a virtualenv,
if you find that convenient too (though I think there are real
advantages to deploying just a big ball of code with no need for
installers). But I see little reason to make virtualenvs
relocatable or
sharable across platforms. I don't think virtualenvs as on on-disk
file
structure make a good distribution/deployment mechanism at all.

IOW, I hijacked this thread (sorry) to respond to a specific
denigration
of the value of virtualenv that I disagree with. I don't care about
making virtualenvs consistent across platforms.


Well, if you're the virtualenv maintainer (or at least the PEP 
author), and you're basically shooting down the principal rationale 
for reorganizing the Windows directory layout, then it's not really 
much of a hijack - it's pretty darn central to the thread!


What I read here is a bit different than Mr Eby read, it seems.

I read Carl as suggesting that keeping deployment copies of virtualenvs 
as foolish, but thinking it is fine to deploy into a virtualenv file 
structure (although preferring to deplay a big ball of code, himself).


Personally, I see application deployment as a big ball of code the 
preferred technique also, but library/module deployment is harder to do 
that way... it sort of defeats the ability to then bundle the 
library/module into the big ball of code for the application.  But if 
the goal is to deploy a big ball of code, that would run on top of an 
installed Python or virtualenv Python, then that is a lot easier if the 
only modules used are Python modules (no C extensions). Such can be 
bundled into a zip file, with little support, such that a relative 
Python novice as myself can figure it out and implement it quickly. C 
extensions cannot be run from a zip file, so then one needs support code 
to unzip the C binaries dynamically, and (possibly) delete them when 
done.  Or am I missing something?


Hmm. And here's something else that might be missing: integration of the 
launcher with .py files that are actually ZIP archives... where does it 
find the #! line? (probably it can't, currently -- I couldn't figure out 
how to make it do it).  Is it possible to add a #! line at the beginning 
of a ZIP archive for the launcher to use, and still have Python 
recognize the result as a ZIP archive? I know self-extracting archives 
put an executable program in front of a ZIP file, and the result is 
still recognized by most ZIP archivers, but I tried just putting a #! 
line followed by a ZIP archive, and Python gave me SyntaxError: unknown 
decode error.


___
Python-Dev mailing list
Python-Dev@python.org
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 install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

2012-03-26 Thread Glenn Linderman

On 3/26/2012 1:21 PM, Glenn Linderman wrote:
Hmm. And here's something else that might be missing: integration of 
the launcher with .py files that are actually ZIP archives... where 
does it find the #! line? (probably it can't, currently -- I couldn't 
figure out how to make it do it).  Is it possible to add a #! line at 
the beginning of a ZIP archive for the launcher to use, and still have 
Python recognize the result as a ZIP archive? I know self-extracting 
archives put an executable program in front of a ZIP file, and the 
result is still recognized by most ZIP archivers, but I tried just 
putting a #! line followed by a ZIP archive, and Python gave me 
SyntaxError: unknown decode error.


OK, my first try there, I forgot the stupid Windows /b switch on copy, 
so apparently the ZIP archive got mangled.


When I use ropy /b to join

#!/usr/bin/python3.2

and a zip file, it now works.  Sorry for the noise.
___
Python-Dev mailing list
Python-Dev@python.org
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 411 - request for pronouncement

2012-03-26 Thread Guido van Rossum
On Fri, Mar 23, 2012 at 2:51 AM, Eli Bendersky  wrote:
> PEP 411 -- Provisional packages in the Python standard library
>
> Has been updated with all accumulated feedback from list discussions.
> Here it is: http://www.python.org/dev/peps/pep-0411/ (the text is also
> pasted in the bottom of this email).
>
> The PEP received mostly positive feedback. The only undecided point is
> where to specify that the package is provisional. Currently the PEP
> mandates to specify it in the documentation and in the docstring.
> Other suggestions were to put it in the code, either as a
> __provisional__ attribute on the module, or collect all such modules
> in a single sys.provisional list.
>
> According to http://blog.python.org/2012/03/2012-language-summit-report.html,
> the PEP was discussed in the language summit and overall viewed
> positively, although no final decision has been reached.
>
> ISTM a decision needs to be taken, which is why I request
> pronouncement, with a recommendation on the requirement the PEP should
> make of provisional modules (process details).

I think the PEP is almost ready for approval. Congratulations! A few comments:

- I'd leave some wiggle room for the docs owner (Georg) about the
exact formulation of the text blurb included for provisional modules
and the glossary entry; I don't want the PEP to have the last word
here.

- I think we are settling on the term "feature release" instead of the
somewhat ambiguous "minor release".

- As was discussed at the language summit, I'd like to emphasize that
the bar for making changes to a provisional package should be
considered pretty high. That is, while we don't make guarantees about
backward compatibility, we still expect that most of the API of most
provisional packages will be unchanged at graduation. Withdrawals
should also be pretty rare.

- Should we limit the duration of the provisional state to 1 or 2
feature releases?

- I'm not sure what to do with regex -- it may be better to just
include in as "re" and keep the old re module around under another
name ("sre" has been proposed half jokingly).

PS. Please use the version in the peps repo as the starting point of
future edits.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
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 393 decode() oddity

2012-03-26 Thread Serhiy Storchaka

26.03.12 01:28, Victor Stinner написав(ла):

Cool, Python 3.3 is *much* faster to decode pure ASCII :-)


He even faster on large data. 1000 characters is not enough to 
completely neutralize the constant costs of the function calls. Python 
3.3 is really cool.



encoding  string 2.7   3.2   3.3

ascii " " * 1000 5.4   5.3   1.2


4.5 faster than Python 2 here.


And it can be accelerated (issue #14419).


utf-8 " " * 1000 6.7   2.4   2.1


3.2x faster


In theory, the speed must coincide with latin1 speed. And it coincides 
in the limit, for large data. For medium data starting overhead cost is 
visible and utf-8 is a bit slower than it could be.



It's cool because in practice, a lot of strings are pure ASCII (as
Martin showed in its Django benchmark).


But there are a lot of non-ascii text. But with mostly-ascii text, 
containing at least one non-ascii character (for example, Martin's full 
name), utf-8 decoder copes much worse. And worse than in Python 3.2.


The decoder may be slower only by a small amount, related to scanning. I 
believe that the stock to optimize exists.



I'm interested by any patch optimizing any Python codecs. I'm not
working on optimizing Python Unicode anymore, various benchmarks
showed me that Python 3.3 is as good or faster than Python 3.2. That's
enough for me.


Then would you accept a patch, proposed by me in issue 14249? This patch 
will not catch up all arrears, but it is very simple and should not 
cause objections. Developed by me now optimization accelerates decoder 
even more, but so far it is too ugly spaghetti-code.



When Python 3.3 is slower than Python 3.2, it's because Python 3.3
must compute the maximum character of the result, and I fail to see
how to optimize this requirement.


A significant slowdown was caused by the use of PyUnicode_WRITE with a 
variable kind in loop. In some cases, it would be useful to expand the 
loop in cascade of independent loops which fallback onto each other (as 
you have already done in utf8_scanner).


___
Python-Dev mailing list
Python-Dev@python.org
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 393 decode() oddity

2012-03-26 Thread Serhiy Storchaka

27.03.12 01:04, Serhiy Storchaka написав(ла):

26.03.12 01:28, Victor Stinner написав(ла):
loop in cascade of independent loops which fallback onto each other (as
you have already done in utf8_scanner).


Sorry. Not you. Antoine Pitrou.

___
Python-Dev mailing list
Python-Dev@python.org
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 393 decode() oddity

2012-03-26 Thread Serhiy Storchaka

25.03.12 23:55, mar...@v.loewis.de написав(ла):

The results are fairly stable (±0.1 µsec) from run to run. It looks
funny thing.


This is not surprising.


Thank you. Indeed, it is logical. I looked at the code and do not see 
how to speed it up.


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


Re: [Python-Dev] cpython: Fix time.steady(strict=True): don't use CLOCK_REALTIME

2012-03-26 Thread Antoine Pitrou
On Mon, 26 Mar 2012 22:53:37 +0200
victor.stinner  wrote:
> http://hg.python.org/cpython/rev/566527ace50b
> changeset:   75960:566527ace50b
> user:Victor Stinner 
> date:Mon Mar 26 22:53:14 2012 +0200
> summary:
>   Fix time.steady(strict=True): don't use CLOCK_REALTIME

Victor, could we have a PEP on all this?
I think everyone has lost track of what you are trying to do with these
new methods.

cheers

Antoine.


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


Re: [Python-Dev] Drop the new time.wallclock() function?

2012-03-26 Thread Zooko Wilcox-O'Hearn
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 enough in my previous post:

Some use cases (timeouts, event scheduling, profiling, sensing)
require a steady clock. Others (calendaring, communicating times to
users, generating times for comparison to remote hosts) require a wall
clock.

Now here's the kicker: each use case incur significant risks if it
uses the wrong kind of clock.

If you're implementing event scheduling or sensing and control, and
you accidentally get a wall clock when you thought you had a steady
clock, then your program may go seriously wrong -- events may fire in
the wrong order, measurements of your sensors may be wildly incorrect.
This can lead to serious accidents. On the other hand, if you're
implementing calendaring or display of "real local time of day" to a
user, and you are using a steady clock for some reason, then you risk
displaying incorrect results to the user.

So using one kind of clock and then "falling back" to the other kind
is a choice that should be rare, explicit, and discouraged. The
provision of such a function in the standard library is an attractive
nuisance -- a thing that people naturally think that they want when
they haven't though about it very carefully, but that is actually
dangerous.

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.

Regards,

Zooko
___
Python-Dev mailing list
Python-Dev@python.org
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] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed

2012-03-26 Thread Stefan Krah
Victor Stinner  wrote:
> > The 80x is a ballpark figure for the maximum expected speedup for
> > standard numerical floating point applications.
> 
> Ok, but it's just surprising when you read the What's New document.
> 72x and 80x look to be inconsistent.

Yes, indeed, I'll reword that.


> > For huge numbers _decimal is also faster than int:
> >
> > factorial(100):
> >
> > _decimal, calculation time: 6.844487905502319
> > _decimal, tostr(): ?? ?? ?? ?? ??0.033592939376831055
> >
> > int, calculation time: 17.96010398864746
> > int, tostr(): ... still running ...
> 
> Hum, with a resolution able to store the result with all digits?

Yes, you have to set context.prec (and emax) to the maximum values,
then the result is an exact integer. The conversion to string is
so fast because there is no complicated base conversion.


> If yes, would it be possible to reuse the multiply algorithm of _decimal
> (and maybe of other functions) for int? Or does it depend heavily on
> _decimal internal structures?

Large parts of the Number Theoretic Transform could be reused, but there
would be still quite a bit of work.


Stefan Krah



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


Re: [Python-Dev] Drop the new time.wallclock() function?

2012-03-26 Thread Victor Stinner
> So using one kind of clock and then "falling back" to the other kind
> is a choice that should be rare, explicit, and discouraged. The
> provision of such a function in the standard library is an attractive
> nuisance -- a thing that people naturally think that they want when
> they haven't though about it very carefully, but that is actually
> dangerous.
>
> 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 clock would be better in some
functions. For these programs, you can replace time.time() by
time.steady() where you need to compute a time delta (e.g. compute a
timeout) to avoid issues with the system clock update. The idea is to
improve the program without refusing to start if no monotonic clock is
available.

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


Re: [Python-Dev] Drop the new time.wallclock() function?

2012-03-26 Thread Glyph

On Mar 26, 2012, at 6:31 PM, Zooko Wilcox-O'Hearn wrote:

> 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 enough in my previous post:
> 
> Some use cases (timeouts, event scheduling, profiling, sensing)
> require a steady clock. Others (calendaring, communicating times to
> users, generating times for comparison to remote hosts) require a wall
> clock.
> 
> Now here's the kicker: each use case incur significant risks if it
> uses the wrong kind of clock.
> 
> If you're implementing event scheduling or sensing and control, and
> you accidentally get a wall clock when you thought you had a steady
> clock, then your program may go seriously wrong -- events may fire in
> the wrong order, measurements of your sensors may be wildly incorrect.
> This can lead to serious accidents. On the other hand, if you're
> implementing calendaring or display of "real local time of day" to a
> user, and you are using a steady clock for some reason, then you risk
> displaying incorrect results to the user.
> 
> So using one kind of clock and then "falling back" to the other kind
> is a choice that should be rare, explicit, and discouraged. The
> provision of such a function in the standard library is an attractive
> nuisance -- a thing that people naturally think that they want when
> they haven't though about it very carefully, but that is actually
> dangerous.
> 
> 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.

I feel that this should be emphasized.  Zooko knows what he's talking about 
here.  Listen to him :).  (Antoine has the right idea.  I think it's well past 
time for a PEP on this feature.)

-glyph

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


[Python-Dev] PEP 418: Add monotonic clock

2012-03-26 Thread Victor Stinner
Hi,

I started to write the PEP 418 to clarify the notions of monotonic and
steady clocks.

The PEP is a draft and everyone is invited to contribute!

http://www.python.org/dev/peps/pep-0418/
http://hg.python.org/peps/file/tip/pep-0418.txt

Victor
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Victor Stinner
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
>
> The PEP is a draft and everyone is invited to contribute!

time.steady() doesn't fit the benchmarking use case: it looks like we
have to decide between stability and clock resolution.

QueryPerformanceCounter() has a good resolution for benchmarking, but
it is not monotonic and so GetTickCount64() would be used for
time.steady(). GetTickCount64() is monotonic but has only a resolution
of 1 millisecond.

We might add a third new function which provides the most accurate
clock with or without a known starting point. We cannot use
QueryPerformanceCounter() to enhance time.time() resolution because it
has an unknown starting point.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Scott Dial
On 3/26/2012 7:32 PM, Victor Stinner wrote:
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.

"""
time.steady
This clock advances at a steady rate relative to real time. It may be
adjusted.
"""

Please do not call this "steady". If the clock can be adjusted, then it
is not "steady" by any acceptable definition. I cannot fathom the
utility of this function other than as a function that provides an
automatic fallback from "time.monotonic()". More importantly: this
definition of "steady" is in conflict with the C++0x definition of
"steady" that is where you sourced this named from![1]

"""
time.steady(strict=False) falls back to another clock if no monotonic
clock is not available or does not work, but it does never fail.
"""

As I say above, that is so far away from what "steady" implies that this
is a misnomer. What you are describing is a best-effort clock, which
sounds a lot more like the C++0x "high resolution" clock.

"""
time.steady(strict=True) raises OSError if monotonic clock fails or
NotImplementedError if the system does not provide a monotonic clock
"""

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? At worst, it generates an "AttributeError" (although that is
not clear from your PEP). What is the use case for "strict=True" that is
not covered by your "time.monotonic()"?

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

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

Rather, it seems you have a particular use-case in mind and have settled
on calling that a "steady" clock despite how it belies its name.

[1]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady

"""
Objects of class steady_clock represent clocks for which values of
time_point advance at a steady rate relative to real time. That is, the
clock may not be adjusted.
"""

-- 
Scott Dial
sc...@scottdial.com
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Zooko Wilcox-O'Hearn
>  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 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.

http://stackoverflow.com/questions/6777278/what-is-the-rationale-for-renaming-monotonic-clock-to-steady-clock-in-chrono

In other words, yes! +1! The C++ standards folks just went through the
process that we're now going through, and if we do it right we'll end
up at the same place they are:

http://en.cppreference.com/w/cpp/chrono/system_clock

"""
system_clock represents the system-wide real time wall clock. It may
not be monotonic: on most systems, the system time can be adjusted at
any moment. It is the only clock that has the ability to map its time
points to C time, and, therefore, to be displayed.

steady_clock: monotonic clock that will never be adjusted

high_resolution_clock: the clock with the shortest tick period available
"""

Note that we don't really have the option of providing a clock which
is "monotonic but not steady" in the sense of "can jump forward but
not back". It is a misunderstanding (doubtless due to the confusing
name "monotonic") to think that such a thing is offered by the
underlying platforms. We can choose to *call* it "monotonic",
following POSIX instead of calling it "steady", following C++.

Regards,

Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Drop the new time.wallclock() function?

2012-03-26 Thread Zooko Wilcox-O'Hearn
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 clock would be better in some functions. For 
> these programs, you can replace time.time() by time.steady() where you need 
> to compute a time delta (e.g. compute a timeout) to avoid issues with the 
> system clock update. The idea is to improve the program without refusing to 
> start if no monotonic clock is available.

I agree that this is a reasonable use case. I think of it as basically
being a kind of backward-compatibility, for situations where an
unsteady clock is okay, and a steady clock isn't available. Twisted
faces a similar issue:

http://twistedmatrix.com/trac/ticket/2424

It might good for use cases like this to explicitly implement the
try-and-fallback, since they might have specific needs about how it is
done. For one thing, some such uses may need to emit a warning, or
even to require the caller to explicitly override, such a refusing to
start if a steady clock isn't available unless the user specifies
"--unsteady-clock-ok".

For motivating examples, consider software written using Twisted >
12.0 or Python > 3.2 which is using a clock to drive real world
sensing and control -- measuring the position of a machine and using
time deltas to calculate the machine's velocity, in order to
automatically control the motion of the machine. For some uses, it is
okay if the measurement could, in rare cases, be drastically wrong.
For other uses, that is not an acceptable risk.

One reason I'm sensitive to this issue is that I work in the field of
security, and making the behavior dependent on the system clock
extends the "reliance set", i.e. the set of things that an attacker
could use against you. For example, if your robot depends on the
system clock for its sensing and control, and if your system clock
obeys NTP, then the set of things that an attacker could use against
you includes your NTP servers. If your robot depends instead on a
steady clock, then NTP servers are not in the reliance set.

Now, if your control platform doesn't have a steady clock, you may
choose to go ahead, while making sure that the NTP servers are
authenticated, or you may choose to disable NTP on the control
platform, etc., but that choice might need to be made explicitly by
the operator, rather than automatically by the library.

Regards,

Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Drop the new time.wallclock() function?

2012-03-26 Thread Matt Joiner
Inside time.steady, there are two different clocks trying to get out.

I think this steady business should be removed sooner rather than later.
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Matt Joiner
So does anyone care to dig into the libstd++/boost/windoze implementation
to see how they each did steady_clock?
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Stephen J. Turnbull
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.

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.

Of course, even better yet would be if the browsers wrote the CSS for you
(which probably wouldn't be too hard, if I knew any XUL, which I don't).

> 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.  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.
___
Python-Dev mailing list
Python-Dev@python.org
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 411 - request for pronouncement

2012-03-26 Thread Eli Bendersky
> I think the PEP is almost ready for approval. Congratulations! A few comments:
>
> - I'd leave some wiggle room for the docs owner (Georg) about the
> exact formulation of the text blurb included for provisional modules
> and the glossary entry; I don't want the PEP to have the last word
> here.

Sure, Georg is free to modify the pep to amend the formulation if he wants to.

>
> - I think we are settling on the term "feature release" instead of the
> somewhat ambiguous "minor release".

Fixed

>
> - As was discussed at the language summit, I'd like to emphasize that
> the bar for making changes to a provisional package should be
> considered pretty high. That is, while we don't make guarantees about
> backward compatibility, we still expect that most of the API of most
> provisional packages will be unchanged at graduation. Withdrawals
> should also be pretty rare.
>

Added this emphasis at the end of the "Criteria for graduation" section.

> - Should we limit the duration of the provisional state to 1 or 2
> feature releases?

Initially the PEP came out with a 1-release limit, but some of the
devs pointed out
(http://mail.python.org/pipermail/python-dev/2012-February/116406.html)
that me should not necessarily restrict ourselves.

>
> - I'm not sure what to do with regex -- it may be better to just
> include in as "re" and keep the old re module around under another
> name ("sre" has been proposed half jokingly).
>

Document updated in the PEPs Hg, rev a1bb0a9af63f.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
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 411 - request for pronouncement

2012-03-26 Thread Guido van Rossum
On Mon, Mar 26, 2012 at 8:23 PM, Eli Bendersky  wrote:
>> I think the PEP is almost ready for approval. Congratulations! A few 
>> comments:
>>
>> - I'd leave some wiggle room for the docs owner (Georg) about the
>> exact formulation of the text blurb included for provisional modules
>> and the glossary entry; I don't want the PEP to have the last word
>> here.
>
> Sure, Georg is free to modify the pep to amend the formulation if he wants to.

Ok. He can do that at any time. :-)

>> - I think we are settling on the term "feature release" instead of the
>> somewhat ambiguous "minor release".
>
> Fixed

Great.

>> - As was discussed at the language summit, I'd like to emphasize that
>> the bar for making changes to a provisional package should be
>> considered pretty high. That is, while we don't make guarantees about
>> backward compatibility, we still expect that most of the API of most
>> provisional packages will be unchanged at graduation. Withdrawals
>> should also be pretty rare.
>>
>
> Added this emphasis at the end of the "Criteria for graduation" section.

Cool.

>> - Should we limit the duration of the provisional state to 1 or 2
>> feature releases?
>
> Initially the PEP came out with a 1-release limit, but some of the
> devs pointed out
> (http://mail.python.org/pipermail/python-dev/2012-February/116406.html)
> that me should not necessarily restrict ourselves.

Gotcha.

>> - I'm not sure what to do with regex -- it may be better to just
>> include in as "re" and keep the old re module around under another
>> name ("sre" has been proposed half jokingly).
>>
>
> Document updated in the PEPs Hg, rev a1bb0a9af63f.

TBH I'm not sure what I meant to say about regex in
http://mail.python.org/pipermail/python-dev/2012-January/115962.html
... But I think if we end up changing the decision about this or any
others that doesn't invalidate this PEP, which is informational PEP
anyway.

I've marked it up as Approved. Thanks, and congrats!

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Scott Dial
On 3/26/2012 10:59 PM, Matt Joiner wrote:
> So does anyone care to dig into the libstd++/boost/windoze
> implementation to see how they each did steady_clock?

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 }

Whether or not these implementations meet the specification is an
exercise left to the reader..

-- 
Scott Dial
sc...@scottdial.com
___
Python-Dev mailing list
Python-Dev@python.org
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 411 - request for pronouncement

2012-03-26 Thread Eli Bendersky
>
> I've marked it up as Approved. Thanks, and congrats!
>

Thanks!

Eli
___
Python-Dev mailing list
Python-Dev@python.org
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 411 - request for pronouncement

2012-03-26 Thread Eli Bendersky
On Tue, Mar 27, 2012 at 05:34, Guido van Rossum  wrote:
> On Mon, Mar 26, 2012 at 8:23 PM, Eli Bendersky  wrote:
>>> I think the PEP is almost ready for approval. Congratulations! A few 
>>> comments:
>>>
>>> - I'd leave some wiggle room for the docs owner (Georg) about the
>>> exact formulation of the text blurb included for provisional modules
>>> and the glossary entry; I don't want the PEP to have the last word
>>> here.
>>
>> Sure, Georg is free to modify the pep to amend the formulation if he wants 
>> to.
>
> Ok. He can do that at any time. :-)
>

Georg, would you like to change the suggested phrasing in the PEP, or
can I go on and add the "provisional package" term to the glossary (in
3.3 only, of course).

Eli
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Matt Joiner
Cheers, that clears things up.
___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Éric Araujo
Hi,

Le 25/03/2012 15:25, Georg Brandl a écrit :
> On 25.03.2012 21:11, Steven D'Aprano wrote:
>> I think it would be better to leave 2.7 with the old theme,
>> to keep it visually distinct from the nifty new theme used
>> with the nifty new 3.2 and 3.3 versions.
> Hmm, -0 here.  I'd like more opinions on this from other devs.

I’m +0 on Steven’s proposal and +1 on whatever you will decide.

Cheers
___
Python-Dev mailing list
Python-Dev@python.org
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, iteration 2

2012-03-26 Thread Stephen J. Turnbull
On Mon, Mar 26, 2012 at 6:42 AM, Terry Reedy  wrote:
>> Of course you can always use a user stylesheet to override our choices.
>
> Can anyone tell me the best way to do that with FireFox?

http://kb.mozillazine.org/UserContent.css

explains clearly enough.  I can't help you with your particular version
since I'm on Mac OS X and Linux, but it works for me there.
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Jeffrey Yasskin
FWIW, I'm not sure you're the right person to drive time PEPs. You
don't seem to have come into it with much knowledge of time, and it's
taken several repetitions for you to take corrections into account in
both this discussion and the Decimal/datetime representation PEP.

On Mon, Mar 26, 2012 at 4:32 PM, Victor Stinner
 wrote:
> Hi,
>
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
>
> The PEP is a draft and everyone is invited to contribute!
>
> http://www.python.org/dev/peps/pep-0418/
> http://hg.python.org/peps/file/tip/pep-0418.txt
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jyasskin%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
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-26 Thread Nick Coghlan
On Tue, Mar 27, 2012 at 3:51 PM, Jeffrey Yasskin  wrote:
> FWIW, I'm not sure you're the right person to drive time PEPs. You
> don't seem to have come into it with much knowledge of time, and it's
> taken several repetitions for you to take corrections into account in
> both this discussion and the Decimal/datetime representation PEP.

The main things required to be a PEP champion are passion and a
willingness to listen to expert feedback and change course in
response. If someone lacks the former, they will lose steam and their
PEP will eventually be abandoned. If they don't listen to expert
feedback, then their PEP will ultimately be rejected (sometimes a PEP
will be rejected anyway as a poor fit for the language *despite* being
responsive to feedback, but that's no slight to the PEP author).

Victor has shown himself to be quite capable of handling those aspects
of the PEP process, and the topics he has recently applied himself to
are ones where it is worthwhile having a good answer in the standard
library for Python 3.3.

Cheers,
Nick.

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