[Python-Dev] Playing with a new theme for the docs, iteration 2
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 ___ 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
On Sun, Mar 25, 2012 at 1:41 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: PJ Eby p...@telecommunity.com writes: 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 he prefers controlling the content viewed by selecting tabs rather than selecting windows, no doubt. 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. Anyway, CSS is supposed to allow the user to impose such constraints herself, so Philip should do so with a local style, rather than ask designers to do it globally. It's madness to expect web designers to hobble the flexibility of a web page to cater preferentially for one minority over others. No, as Glenn points out, designers (I wouldn't call them *web* designers since they clearly have no intention of taking advantage of the power of the web in design, even if they incorporate links in their pages!) frequently do exactly that. (The minority of one in question being the designer himself!) So it's rational to expect it. :-( However, I believe that CSS also gives us the power to undo such bloodymindedness, though I've never gone to the trouble of learning how. Steve ___ 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
Georg Brandl g.bra...@gmx.net writes: Here's another try, mainly with default browser font size, more contrast and collapsible sidebar again: http://www.python.org/~gbrandl/build/html2/ Great! You've improved it nicely. I especially like that you have URL:https://en.wikipedia.org/wiki/Unobtrusive_JavaScript done the collapsible sidebar with graceful degradation: the content is quite accessible without ECMAscript. Can you make the link colors (in the body and sidebar) follow the usual conventions: use a blue colour for unvisited links, and a purple colour for visited links URL:http://www.useit.com/alertbox/20040510.html so it's more obvious where links are and where the reader has already been. -- \ “I distrust those people who know so well what God wants them | `\to do to their fellows, because it always coincides with their | _o__) own desires.” —Susan Brownell Anthony, 1896 | Ben Finney ___ 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
On Sun, Mar 25, 2012 at 08:34, Georg Brandl g.bra...@gmx.net 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). Nice and clean. +1 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] Playing with a new theme for the docs, iteration 2
On 3/24/2012 11:34 PM, Georg Brandl wrote: 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). It would be educational to see how you pulled that trick! I will look if I get time. However, in playing with it, it has the definite disadvantage of forcing the user to position/click the mouse twice, if the goal is not to collapse the sidebar, but simply to make the content visible. Might there be an additional way to move the content, perhaps by a click in the blank portions of the sidebar (above the top or below the bottom of the content, in the shaded area), that it would bring the content to view? The position chosen for the content could happily be the same position you choose when doing the collapse/expand dance, I have no quibble with that. ___ 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
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/ Nice! Lightweight and readable. From the bikeshedding department: * Inlined code doesn't need the gray background. The bold font makes it stand out enough. * Instead of the box consider italics or another color for [New in ...] text. * Nobody is going to switch off the prompts for interactive sessions. * Maybe the Next/Previous Page headers on the left could link to the respective page. * Short descriptions in the module index don't need italics. * The disambiguation in the index table could use a different style instead of the parentheses. ___ 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
25.03.12 09:34, Georg Brandl написав(ла): Here's another try, mainly with default browser font size, more contrast and collapsible sidebar again: It may be worth now the line-height reduce too? 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). What if move the search field to the header and the footer? There a lot of free space. Report a Bug and Show Source can also be moved to the footer, if fit. The footer height is too big now, I think that you can reduce the copyright and technical information from 4 to 2 lines. ___ 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
25.03.12 11:06, Peter Otten написав(ла): * Inlined code doesn't need the gray background. The bold font makes it stand out enough. I believe that the gray background is good, but it should make it lighter. * Instead of the box consider italics or another color for [New in ...] text. Yes, the border around New in and Changed in looks not good-looking. Maybe a very light colored background with no border or underlined italic will look better. * Maybe the Next/Previous Page headers on the left could link to the respective page. Do you mean next/previous links in header/footer? I totally agree with your other comments, including the admiration of the current version of the design. ___ 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
I like to always see Quick search widget without scrolling page to top. Is it possible? Or maybe you can embed some keyboard shortcut for quick jump to search input box? On Sun, Mar 25, 2012 at 11:44 AM, Serhiy Storchaka storch...@gmail.com wrote: 25.03.12 11:06, Peter Otten написав(ла): * Inlined code doesn't need the gray background. The bold font makes it stand out enough. I believe that the gray background is good, but it should make it lighter. * Instead of the box consider italics or another color for [New in ...] text. Yes, the border around New in and Changed in looks not good-looking. Maybe a very light colored background with no border or underlined italic will look better. * Maybe the Next/Previous Page headers on the left could link to the respective page. Do you mean next/previous links in header/footer? I totally agree with your other comments, including the admiration of the current version of the design. ___ 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/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ 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
In the header next to Python v3.3a1 documentation there is a » symbol, which suggests something can be expanded. Knowing that there are many versions of the documentation, I thought it might bring up a menu of versions. But clicking does nothing. Is that intentional? I guess it's supposed to mean go to top but that wasn't obvious to me. I think the clickable areas in the header and footer should be indicated with the usual coloring (either the scheme you currently use, or perhaps as Ben suggests blue and purple as in traditional HTML documents). I agree that what you do looks nice and is sufficiently functional once you realize it, but I've seen a lot of research that indicates that up to 60% of users can't find all the links on a page unless they're explicitly marked. (In one focus group 4 of 14 users never found a menu that took up 40% of the area of the page!) My first impression of the questionable feature that the sidebar is aligned with the scroll position when expanded is that it's useful. It looks pretty good without CSS, too! On Sun, Mar 25, 2012 at 8:34 AM, Georg Brandl g.bra...@gmx.net 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 ___ 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/stephen%40xemacs.org ___ 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
25.03.12 09:34, Georg Brandl написав(ла): 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). I'm not sure if this is possible, and how good it would look like, but I have one crazy idea. What if transform the sidebar to collapsable floating box in the upper right corner? ___ 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
Andrew Svetlov andrew.svet...@gmail.com wrote: I like to always see Quick search widget without scrolling page to top. Is it possible? Do you mean a fixed search box like this one? http://coq.inria.fr/documentation Please don't do this, I find scrolling exceptionally distracting in the presence of fixed elements. 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] Playing with a new theme for the docs, iteration 2
On Sun, Mar 25, 2012 at 12:04 PM, Stefan Krah ste...@bytereef.org wrote: Andrew Svetlov andrew.svet...@gmail.com wrote: I like to always see Quick search widget without scrolling page to top. Is it possible? Do you mean a fixed search box like this one? http://coq.inria.fr/documentation No. You are right, it's distracting. Maybe narrow persistent line with searchbox on the top will be better. But just jump to searchbox by shortcut is good enough for me also. Please don't do this, I find scrolling exceptionally distracting in the presence of fixed elements. 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/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ 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
Hi Georg, Am 25.03.2012 um 08:34 schrieb Georg Brandl: Here's another try, mainly with default browser font size, more contrast and collapsible sidebar again: http://www.python.org/~gbrandl/build/html2/ I really like it! Only one nitpick: If a header follows on a “seealso”, the vertical rhythm is slightly broken like in https://skitch.com/hyneks/8c6j8/ Minor detail but should be easy to fix. :) Cheers, Hynek ___ 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] AUTO: Jon K Peck is out of the office (returning 03/30/2012)
I am out of the office until 03/30/2012. I will be out of the office through Friday, March 30. I expect to have some email access but may be delayed in responding. Note: This is an automated response to your message Python-Dev Digest, Vol 104, Issue 91 sent on 03/25/2012 1:19:50. This is the only notification you will receive while this person is away. ___ 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
Serhiy Storchaka wrote: * Maybe the Next/Previous Page headers on the left could link to the respective page. Do you mean next/previous links in header/footer? No, I mean the two sections in the sidebar on the left, below Table of Contents. ___ 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
On Sun, Mar 25, 2012 at 11:04 AM, Stefan Krah ste...@bytereef.org wrote: Do you mean a fixed search box like this one? http://coq.inria.fr/documentation Please don't do this, I find scrolling exceptionally distracting in the presence of fixed elements. Does it bother you when the header is fixed and contains the search box? I prefer that arrangement, anyway. ___ 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
On Sun, Mar 25, 2012 at 08:34:44AM +0200, Georg Brandl wrote: http://www.python.org/~gbrandl/build/html2/ Perfect! I like it! Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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
Is nice yes?! When I small the nav bar, then embiggen it again, the text centers vertically. It's in the wrong place. The new theme is very minimal, perhaps a new color should be chosen. We've done green, what about orange, brown or blue? ___ 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
On Sun, 25 Mar 2012 08:34:44 +0200 Georg Brandl g.bra...@gmx.net 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). The gimmick is buggy (when you collapse then expand it in the middle, and then scroll up, the sidebar content disappears after scrolling), and in the end quite confusing. Also I think there should be some jquery animation when collapsing/expanding. I think the New in version... and Changed in version... styles stand out in the wrong kind of way (as in drawn by a 8-year old with a pen and ruler, perhaps). Perhaps you want some coloured background instead? (or, better, an icon - by the way, warnings also scream for an icon IMO) Otherwise, not sure what problem this new theme solves, but it looks ok. 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] Playing with a new theme for the docs, iteration 2
Stephen J. Turnbull step...@xemacs.org wrote: Do you mean a fixed search box like this one? http://coq.inria.fr/documentation Please don't do this, I find scrolling exceptionally distracting in the presence of fixed elements. Does it bother you when the header is fixed and contains the search box? I prefer that arrangement, anyway. Do you have an example website? In general fixed elements distract me greatly. This also applies to the '' element in the collapsible sidebar. When I'm scrolling, it's almost the center of my attention (when I should be focusing on the text). Perhaps users can discover the collapsible sidebar without the '' hint? Or let it move up like in the existing version? 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] Playing with a new theme for the docs, iteration 2
On Sun, Mar 25, 2012 at 2:34 PM, Stefan Krah ste...@bytereef.org wrote: Stephen J. Turnbull step...@xemacs.org wrote: Does it bother you when the header is fixed and contains the search box? I prefer that arrangement, anyway. Do you have an example website? Not with just a header. http://turnbull.sk.tsukuba.ac.jp/Teach/IntroSES/ is a (very primitive and not stylistically improved in years) example of a frame-based layout that I use some of my classes. I would put a search field in the top frame (if I had one. :-) But I suppose you would find the fixed sidebar distracting. In general fixed elements distract me greatly. This also applies to the '' element in the collapsible sidebar. When I'm scrolling, it's almost the center of my attention (when I should be focusing on the text). I suspect you're unusual in that, but I guess it just is going to bug you no matter what, and I personally don't have *that* strong a preference either way. ___ 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
On Sun, Mar 25, 2012 at 07:07, Antoine Pitrou solip...@pitrou.net wrote: 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). The gimmick is buggy (when you collapse then expand it in the middle, and then scroll up, the sidebar content disappears after scrolling), and in the end quite confusing. It also seems not to handle window resizes very well right now. It appears to choose the height for the vertical bar when shown, and then when the text next to it reflows to a new length, the bar can become longer or shorter than necessary. On the one hand this makes it hard to get the sidebar content to show at the bottom of the page; on the other, I believe it mitigates potential problems if sidebar content is too long for the window size. -- Michael Urman ___ 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
On 3/25/2012 2:34 AM, 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/ Georg, thanks so much for taking on this thankless task with grace and skill. It can't be easy dealing with the death by a thousand tweaks, and I know I've contributed to the flurry. Nowhere on the page is a simple link to the front page of python.org. Perhaps the traditional upper-left corner could get a bread-crumb before Python v3.3a1 documentation that simply links to python.org. Maybe, use the word Python that is already there: [Python] » [v3.3a1 documentation]. People do arrive at doc pages via search engines, and connecting the docs up to the rest of the site would be a good thing. Speaking of links to other pages, the doc front page, under Other resources lists Guido's Essays and New-style Classes second and third. These each point to extremely outdated material (Unifying types and classes in 2.2, and Unfortunately, new-style classes have not yet been integrated into Python's standard documention. ??). Another, Other Doc Collections, points to an empty apache-style directory listing :-(. These links should be removed if we don't want to keep those sections of the site up-to-date. I know this is not strictly part of the redesign, but I just noticed it and thought I would throw it out there. I agree about the outlined style for New notices, and the red for deprecation is extremely alarming! :) I'll make one last plea for not justifying short paragraphs full of unbreakable elements, but I know I am in the minority. 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). I especially like using dynamic elements on a page to adapt to a reader's needs. I have some other ideas that I'll try to cobble together. --Ned. Have fun! 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/ned%40nedbatchelder.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
On 25/03/2012 16:26, Ned Batchelder wrote: Georg, thanks so much for taking on this thankless task with grace and skill. It can't be easy dealing with the death by a thousand tweaks Seconded. I'm constantly edified by the way in which people in the community respond to even quite abrupt criticism in a constructive, open and often humorous manner. (As I've said before, I'm also impressed by the way in which people are prepared to come back and apologise / acknowledge that they had a moment of jerkiness). TJG ___ 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
On 3/25/2012 2:34 AM, Georg Brandl wrote: Here's another try, mainly with default browser font size, more contrast Untrue. You still changed the high contrast dark blue to the same low contrast light blue for builtin names, etc. What problem do you think you are trying to solve by making the doc difficult and even PAINFUL for me to read? - a lot more than 1 -- 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, iteration 2
Stephen J. Turnbull step...@xemacs.org wrote: Not with just a header. http://turnbull.sk.tsukuba.ac.jp/Teach/IntroSES/ is a (very primitive and not stylistically improved in years) example of a frame-based layout that I use some of my classes. I would put a search field in the top frame (if I had one. :-) But I suppose you would find the fixed sidebar distracting. No, if the whole sidebar is fixed I don't mind (though I'm not a fan of frames). The top frame takes up space though. In general fixed elements distract me greatly. This also applies to the '' element in the collapsible sidebar. When I'm scrolling, it's almost the center of my attention (when I should be focusing on the text). I suspect you're unusual in that, but I guess it just is going to bug you no matter what, and I personally don't have *that* strong a preference either way. Maybe. It's hard to determine. It's just that I don't see fixed search boxes or fixed elements like '' on big name websites (who may or may not have usability departments). So it is at least possible that such features have always been controversial. 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] Playing with a new theme for the docs, iteration 2
On 25.03.2012 09:19, Ben Finney wrote: Georg Brandl g.bra...@gmx.net writes: Here's another try, mainly with default browser font size, more contrast and collapsible sidebar again: http://www.python.org/~gbrandl/build/html2/ Great! You've improved it nicely. I especially like that you have URL:https://en.wikipedia.org/wiki/Unobtrusive_JavaScript done the collapsible sidebar with graceful degradation: the content is quite accessible without ECMAscript. Can you make the link colors (in the body and sidebar) follow the usual conventions: use a blue colour for unvisited links, and a purple colour for visited links URL:http://www.useit.com/alertbox/20040510.html so it's more obvious where links are and where the reader has already been. Thanks. Same colors for visited and unvisited links is indeed an oversight on my part. I'll put that in the final version. 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
On 25.03.2012 17:26, Ned Batchelder wrote: On 3/25/2012 2:34 AM, 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/ Georg, thanks so much for taking on this thankless task with grace and skill. It can't be easy dealing with the death by a thousand tweaks, and I know I've contributed to the flurry. Nowhere on the page is a simple link to the front page of python.org. Perhaps the traditional upper-left corner could get a bread-crumb before Python v3.3a1 documentation that simply links to python.org. Maybe, use the word Python that is already there: [Python] » [v3.3a1 documentation]. People do arrive at doc pages via search engines, and connecting the docs up to the rest of the site would be a good thing. Indeed. I'm trying to tweak that right now. Speaking of links to other pages, the doc front page, under Other resources lists Guido's Essays and New-style Classes second and third. These each point to extremely outdated material (Unifying types and classes in 2.2, and Unfortunately, new-style classes have not yet been integrated into Python's standard documention. ??). Another, Other Doc Collections, points to an empty apache-style directory listing :-(. These links should be removed if we don't want to keep those sections of the site up-to-date. I know this is not strictly part of the redesign, but I just noticed it and thought I would throw it out there. That would be best to capture in a bugs.python.org issue, I think. I agree about the outlined style for New notices, and the red for deprecation is extremely alarming! :) Changed. I'll make one last plea for not justifying short paragraphs full of unbreakable elements, but I know I am in the minority. :) 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). I especially like using dynamic elements on a page to adapt to a reader's needs. I have some other ideas that I'll try to cobble together. That would be great. 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
On 25.03.2012 10:06, Peter Otten wrote: 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/ Nice! Lightweight and readable. From the bikeshedding department: * Inlined code doesn't need the gray background. The bold font makes it stand out enough. * Instead of the box consider italics or another color for [New in ...] text. Yes, I'll revert to italics as most people don't seem to like the colored boxes. * Nobody is going to switch off the prompts for interactive sessions. You'll laugh, but that was a pretty often-wished feature so that copy-paste gets easier. It'll certainly stay. * Maybe the Next/Previous Page headers on the left could link to the respective page. I see no reason since the links below already do. * Short descriptions in the module index don't need italics. * The disambiguation in the index table could use a different style instead of the parentheses. These two would need to be changed in Sphinx. 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
[Python-Dev] PEP 393 decode() oddity
PEP 393 (Flexible String Representation) is, without doubt, one of the
pearls of the Python 3.3. In addition to reducing memory consumption, it
also often leads to a corresponding increase in speed. In particular,
the string encoding now in 1.5-3 times faster.
But decoding is not so good. Here are the results of measuring the
performance of the decoding of the 1000-character string consisting of
characters from different ranges of the Unicode, for three versions of
Python -- 2.7.3rc2, 3.2.3rc2+ and 3.3.0a1+. Little-endian 32-bit i686
builds, gcc 4.4.
encoding string 2.7 3.2 3.3
ascii * 1000 5.4 5.3 1.2
latin1 * 1000 1.8 1.7 1.3
latin1\u0080 * 10001.7 1.6 1.0
utf-8 * 1000 6.7 2.4 2.1
utf-8 \u0080 * 1000 12.2 11.0 13.0
utf-8 \u0100 * 1000 12.2 11.1 13.6
utf-8 \u0800 * 1000 14.7 14.4 17.2
utf-8 \u8000 * 1000 13.9 13.3 17.1
utf-8 \U0001 * 1000 17.3 17.5 21.5
utf-16le* 1000 5.5 2.9 6.5
utf-16le \u0080 * 10005.5 2.9 7.4
utf-16le \u0100 * 10005.5 2.9 8.9
utf-16le \u0800 * 10005.5 2.9 8.9
utf-16le \u8000 * 10005.5 7.5 21.3
utf-16le \U0001 * 10009.6 12.9 30.1
utf-16be* 1000 5.5 3.0 9.0
utf-16be \u0080 * 10005.5 3.1 9.8
utf-16be \u0100 * 10005.5 3.1 10.4
utf-16be \u0800 * 10005.5 3.1 10.4
utf-16be \u8000 * 10005.5 6.6 21.2
utf-16be \U0001 * 10009.6 11.2 28.9
utf-32le* 100010.2 10.4 15.1
utf-32le \u0080 * 1000 10.0 10.4 16.5
utf-32le \u0100 * 1000 10.0 10.4 19.8
utf-32le \u0800 * 1000 10.0 10.4 19.8
utf-32le \u8000 * 1000 10.1 10.4 19.8
utf-32le \U0001 * 1000 11.7 11.3 20.2
utf-32be* 100010.0 11.2 15.0
utf-32be \u0080 * 1000 10.1 11.2 16.4
utf-32be \u0100 * 1000 10.0 11.2 19.7
utf-32be \u0800 * 1000 10.1 11.2 19.7
utf-32be \u8000 * 1000 10.1 11.2 19.7
utf-32be \U0001 * 1000 11.7 11.2 20.2
The first oddity in that the characters from the second half of the
Latin1 table decoded faster than the characters from the first half. I
think that the characters from the first half of the table must be
decoded as quickly.
The second sad oddity in that UTF-16 decoding in 3.3 is much slower than
even in 2.7. Compared with 3.2 decoding is slower in 2-3 times. This is
a considerable regress. UTF-32 decoding is also slowed down by 1.5-2 times.
The fact that in some cases UTF-8 decoding also slowed, is not
surprising. I believe, that on a platform with a 64-bit long, there may
be other oddities.
How serious a problem this is for the Python 3.3 release? I could do the
optimization, if someone is not working on this already.
# -*- coding: utf-8 -*-
import codecs, timeit
def bench_decode(encoding, string):
try:
x = eval(string).encode(encoding)
except UnicodeEncodeError:
return
setup = '''
import codecs
d = codecs.getdecoder({encoding!r})
x = {x!r}
'''.format(encoding=encoding, x=x)
t = timeit.Timer('d(x)', setup)
repeat = 10
number = 1
precision = 3
r = t.repeat(repeat, number)
best = min(r)
usec = best * 1e6 / number
print(%-8s %-20s %4.1f % (encoding, string, usec))
for encoding in ('ascii', 'latin1', 'utf-8', 'utf-16le', 'utf-16be', 'utf-32le', 'utf-32be'):
for string in (' * 1000', '\\u0080 * 1000', '\\u0100 * 1000', '\\u0800 * 1000', '\\u8000 * 1000', '\\U0001 * 1000'):
bench_decode(encoding, string)
print()
# -*- coding: utf-8 -*-
import codecs, timeit
def bench_decode(encoding, string):
try:
x = eval(string).encode(encoding)
except UnicodeEncodeError:
return
setup = '''
import codecs
d = codecs.getdecoder({encoding!r})
x = {x!r}
'''.format(encoding=encoding, x=x)
t = timeit.Timer('d(x)', setup)
repeat = 10
number = 1
precision = 3
r = t.repeat(repeat, number)
best = min(r)
usec = best * 1e6 / number
print(%-8s %-20s %4.1f % (encoding, string, usec))
for encoding in ('ascii', 'latin1', 'utf-8', 'utf-16le', 'utf-16be', 'utf-32le', 'utf-32be'):
for string in ('u * 1000', 'u\\u0080 * 1000', 'u\\u0100 * 1000', 'u\\u0800 * 1000', 'u\\u8000 * 1000', 'u\\U0001 * 1000'):
bench_decode(encoding, string)
print
___
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
On 25.03.2012 17:54, Terry Reedy wrote: On 3/25/2012 2:34 AM, Georg Brandl wrote: Here's another try, mainly with default browser font size, more contrast Untrue. You still changed the high contrast dark blue to the same low contrast light blue for builtin names, etc. What problem do you think you are trying to solve by making the doc difficult and even PAINFUL for me to read? - a lot more than 1 More contrast was meant in comparison to iteration #1. Hmm, don't you think you'll get used to the new style in a while? The link color is not actually that light in comparison. Of course you can always use a user stylesheet to override our choices. 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
On 25.03.2012 13:09, Stephen J. Turnbull wrote: On Sun, Mar 25, 2012 at 11:04 AM, Stefan Krah ste...@bytereef.org wrote: Do you mean a fixed search box like this one? http://coq.inria.fr/documentation Please don't do this, I find scrolling exceptionally distracting in the presence of fixed elements. Does it bother you when the header is fixed and contains the search box? I prefer that arrangement, anyway. I think this idea has some merit. I'd prefer it to be tried out and implemented in a second step though (maybe by someone else, even? ;) 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] PEP 393 decode() oddity
Hi, On Sun, 25 Mar 2012 19:25:10 +0300 Serhiy Storchaka storch...@gmail.com wrote: But decoding is not so good. The general problem with decoding is that you don't know up front what width (1, 2 or 4 bytes) is required for the result. The solution is either to compute the width in a first pass (and decode in a second pass), or decode in a single pass and enlarge the result on the fly when needed. Both incur a slowdown compared to a single-size representation. The first oddity in that the characters from the second half of the Latin1 table decoded faster than the characters from the first half. I think that the characters from the first half of the table must be decoded as quickly. It's probably a measurement error on your part. The second sad oddity in that UTF-16 decoding in 3.3 is much slower than even in 2.7. Compared with 3.2 decoding is slower in 2-3 times. This is a considerable regress. UTF-32 decoding is also slowed down by 1.5-2 times. I don't think UTF-32 is used a lot. As for UTF-16, if you can optimize it then why not. 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] PEP 393 decode() oddity
How serious a problem this is for the Python 3.3 release? I could do the optimization, if someone is not working on this already. I think the people who did the original implementation (Torsten, Victor, and myself) are done with optimizations. So: contributions are welcome. I'm not aware of any release-critical performance degradation (but I'd start with string formatting if I were you). ___ 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
On 25.03.2012 08:34, 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). 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. Please make further suggestions (preferably with patches) through the bug tracker. cheers, 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] PEP 393 decode() oddity
25.03.12 20:01, Antoine Pitrou написав(ла): The general problem with decoding is that you don't know up front what width (1, 2 or 4 bytes) is required for the result. The solution is either to compute the width in a first pass (and decode in a second pass), or decode in a single pass and enlarge the result on the fly when needed. Both incur a slowdown compared to a single-size representation. We can significantly reduce the number of checks, using the same trick that is used for fast checking of surrogate characters. While all characters U+0100, we know that the result is a 1-byte string (ascii while all characters U+0080). When meet a character = U+0100, while all characters U+1, we know that the result is the 2-byte string. As soon as we met first character = U+1, we work with 4-bytes string. There will be several fast loops, the transition to the next loop will occur after the failure in the previous one. It's probably a measurement error on your part. Anyone can test. $ ./python -m timeit -s 'enc = latin1; import codecs; d = codecs.getdecoder(enc); x = (\u0020 * 10).encode(enc)' 'd(x)' 1 loops, best of 3: 59.4 usec per loop $ ./python -m timeit -s 'enc = latin1; import codecs; d = codecs.getdecoder(enc); x = (\u0080 * 10).encode(enc)' 'd(x)' 1 loops, best of 3: 28.4 usec per loop The results are fairly stable (±0.1 µsec) from run to run. It looks funny thing. ___ 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
Not sure if you addressed this in your answers to other comments... Scroll down the page. Minimize the nav bar on the left. Bring it back out again. Now the text in the nav bar permanently starts at an offset from the top of the page. On Sun, Mar 25, 2012 at 7:44 PM, Matt Joiner anacro...@gmail.com wrote: Is nice yes?! When I small the nav bar, then embiggen it again, the text centers vertically. It's in the wrong place. The new theme is very minimal, perhaps a new color should be chosen. We've done green, what about orange, brown or blue? ___ 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
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. -- Steven ___ 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
On 25 March 2012 19:51, Serhiy Storchaka storch...@gmail.com wrote:
Anyone can test.
$ ./python -m timeit -s 'enc = latin1; import codecs; d =
codecs.getdecoder(enc); x = (\u0020 * 10).encode(enc)' 'd(x)'
1 loops, best of 3: 59.4 usec per loop
$ ./python -m timeit -s 'enc = latin1; import codecs; d =
codecs.getdecoder(enc); x = (\u0080 * 10).encode(enc)' 'd(x)'
1 loops, best of 3: 28.4 usec per loop
The results are fairly stable (±0.1 µsec) from run to run. It looks funny
thing.
Hmm, yes. I see the same results. Odd.
PS D:\Data py -3.3 -m timeit -s enc = 'latin1'; import codecs; d =
codecs.getdecoder(enc); x = ('\u0020' * 10).encode(enc) d(x)
1 loops, best of 3: 37.3 usec per loop
PS D:\Data py -3.3 -m timeit -s enc = 'latin1'; import codecs; d =
codecs.getdecoder(enc); x = ('\u0080' * 10).encode(enc) d(x)
10 loops, best of 3: 18 usec per loop
PS D:\Data py -3.3 -m timeit -s enc = 'latin1'; import codecs; d =
codecs.getdecoder(enc); x = ('\u0020' * 10).encode(enc) d(x)
1 loops, best of 3: 37.6 usec per loop
PS D:\Data py -3.3 -m timeit -s enc = 'latin1'; import codecs; d =
codecs.getdecoder(enc); x = ('\u0080' * 10).encode(enc) d(x)
10 loops, best of 3: 18.3 usec per loop
PS D:\Data py -3.3 -m timeit -s enc = 'latin1'; import codecs; d =
codecs.getdecoder(enc); x = ('\u0020' * 10).encode(enc) d(x)
1 loops, best of 3: 37.8 usec per loop
PS D:\Data py -3.3 -m timeit -s enc = 'latin1'; import codecs; d =
codecs.getdecoder(enc); x = ('\u0080' * 10).encode(enc) d(x)
10 loops, best of 3: 18.3 usec per loop
Paul.
___
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
On 25.03.2012 21:09, Matt Joiner wrote: Not sure if you addressed this in your answers to other comments... Scroll down the page. Minimize the nav bar on the left. Bring it back out again. Now the text in the nav bar permanently starts at an offset from the top of the page. Yes, that was the intention I mentioned in my post. That has been removed though from the final version I checked in. There are certainly much better solutions. 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
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. 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] Rename time.steady(strict=True) to time.monotonic()?
On 3/24/2012 6:37 AM, Victor Stinner wrote: - time.monotonic(): monotonic clock, its speed may or may not be adjusted by NTP but it only goes forward, may raise an OSError - time.steady(): monotonic clock or the realtime clock, depending on what is available on the platform (use monotonic in priority). may be adjusted by NTP or the system administrator, may go backward. I am surprised that a clock with the name time.steady() has a looser definition than one called time.monotonic(). To my mind a steady clock is by definition monotonic but a monotonic one may or may not be steady. Do you suggest another name? Victor I can't think of a word or short phrase that adequately describes that behavior, no. But that may just be because I also don't see any use case for it either. To me the more useful function would be one that used the OS monotonic clock when available and failing that used the realtime clock but cached the previous returned value and ensured that all values returned obeyed the monotonic property still. But I don't see why that function shouldn't just be time.monotonic(). Janzert ___ 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
I like to see new schema only for 3.3 as sign of shiny new release. On Sun, Mar 25, 2012 at 10:25 PM, Georg Brandl g.bra...@gmx.net 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. 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/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ 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 czar for PEP 3144?
On Mon, Mar 19, 2012 at 2:50 PM, Ethan Furman et...@stoneleaf.us wrote: [1] I'm assuming that 'iter(some_list)' is a quick operation. This seems to be the case so I've just gone ahead and renamed collapse_address_list to collapse_addresses and added 'return iter(...)' to the end. The rest of the list-returning methods all return iterators now too. There should only be a few minor outstanding issues to to work out. Cheers, peter -- Peter Moody Google 1.650.253.7306 Security Engineer pgp:0xC3410038 ___ 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
Anyone can test. $ ./python -m timeit -s 'enc = latin1; import codecs; d = codecs.getdecoder(enc); x = (\u0020 * 10).encode(enc)' 'd(x)' 1 loops, best of 3: 59.4 usec per loop $ ./python -m timeit -s 'enc = latin1; import codecs; d = codecs.getdecoder(enc); x = (\u0080 * 10).encode(enc)' 'd(x)' 1 loops, best of 3: 28.4 usec per loop The results are fairly stable (±0.1 µsec) from run to run. It looks funny thing. This is not surprising. When decoding Latin-1, it needs to determine whether the string is pure ASCII or not. If it is not, it must be all Latin-1 (it can't be non-Latin-1). For a pure ASCII string, it needs to scan over the entire string, trying to find a non-ASCII character. If there is none, it has to inspect the entire string. In your example, as the first character is is already above 127, search for the maximum character can stop, so it needs to scan the string only once. Try '\u0020' * 99+'\u0080', which is a non-ASCII string but still takes the same time as the pure ASCII string. Regards, Martin ___ 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
On Sun, Mar 25, 2012 at 9:25 PM, Georg Brandl g.bra...@gmx.net 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. Georg I would definitely like the new theme on 2.7 docs as well, since 2.7 is still supported. Cheers, fijal ___ 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
On Sun, Mar 25, 2012 at 14:50, Andrew Svetlov andrew.svet...@gmail.com wrote: I like to see new schema only for 3.3 as sign of shiny new release. Please don't do this. It will result in endless complaints. ___ 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
Brian Curtin br...@python.org writes: On Sun, Mar 25, 2012 at 14:50, Andrew Svetlov andrew.svet...@gmail.com wrote: I like to see new schema only for 3.3 as sign of shiny new release. Please don't do this. It will result in endless complaints. Complaints of what nature? Do you think those complaints are justified? -- \“… Nature … is seen to do all things herself and through | `\ herself of own accord, rid of all gods.” —Titus Lucretius | _o__) Carus, c. 40 BCE | Ben Finney ___ 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
On 3/25/2012 12:32 PM, Georg Brandl wrote: On 25.03.2012 17:54, Terry Reedy wrote: On 3/25/2012 2:34 AM, Georg Brandl wrote: Here's another try, mainly with default browser font size, more contrast Untrue. You still changed the high contrast dark blue to the same low contrast light blue for builtin names, etc. What problem do you think you are trying to solve by making the doc difficult and even PAINFUL for me to read? - a lot more than 1 More contrast was meant in comparison to iteration #1. It is still subjectively dim enough to me that I could not tell from memory. I ran the following experiment: I put old and new versions of the buitin functions page side-by-side in separate browser windows. I asked my teenage daughter to come into the room, approach slowly, and say when she could read one or both windows. At about 5 feet, she could (just) read the old but not the new. If other people repeat the experiment and get the same result, it would then be fair to say that the new style is objectively less readable in regard to this one aspect. Hmm, don't you think you'll get used to the new style in a while? This is a bit like asking a wheelchair user if he would get used to having a ramp ground down to add little one-inch steps every two feet, because leg-abled people found that somehow more aesthetic. Answer: somewhat. Wired magazine has used a similar thin blue font. I got used to that by ignoring any text written with it. The link color is not actually that light in comparison. Using a magnifying glass, the difference seems to be more one of thickness -- 2 pixel lines versus 1-1.5 pixel lines. I have astigmatism that is only partly correctable and the residual blurring of single-pixel lines tends to somewhat mix text color with the background color. 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? Is it even possible with the Windows help version, which is what I usually use? -- 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] PEP 393 decode() oddity
Cool, Python 3.3 is *much* faster to decode pure ASCII :-) encoding string 2.7 3.2 3.3 ascii * 1000 5.4 5.3 1.2 4.5 faster than Python 2 here. utf-8 * 1000 6.7 2.4 2.1 3.2x faster It's cool because in practice, a lot of strings are pure ASCII (as Martin showed in its Django benchmark). latin1 * 1000 1.8 1.7 1.3 latin1\u0080 * 10001.7 1.6 1.0 ... The first oddity in that the characters from the second half of the Latin1 table decoded faster than the characters from the first half. The Latin1 decoder of Python 3.3 is *faster* than the decoder of Python 2.7 and 3.2 according to your bench. So I don't see any issue here :-) Martin explained why it is slower for pure ASCII. I think that the characters from the first half of the table must be decoded as quickly. The Latin1 decoder is already heavily optimized, I don't see how to make it faster. The second sad oddity in that UTF-16 decoding in 3.3 is much slower than even in 2.7. Compared with 3.2 decoding is slower in 2-3 times. This is a considerable regress. UTF-32 decoding is also slowed down by 1.5-2 times. Only ASCII, latin1 and UTF-8 decoder are heavily optimized. We can do better for UTF-16 and UTF-32. I'm just less motivated because UTF-16/32 are less common than ASCII/latin1/UTF-8. How serious a problem this is for the Python 3.3 release? I could do the optimization, if someone is not working on this already. 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. 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. I already introduced many fast-path where it was possible, like creating a substring of an ASCII string (the result is ASCII, no need to scan the substring). It doesn't mean that it is no more possible to optimize Python Unicode ;-) 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] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed
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. 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? 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? 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] Playing with a new theme for the docs, iteration 2
Terry Reedy wrote:
On 3/25/2012 12:32 PM, Georg Brandl wrote:
On 25.03.2012 17:54, Terry Reedy wrote:
On 3/25/2012 2:34 AM, Georg Brandl wrote:
Here's another try, mainly with default browser font size, more
contrast
Untrue. You still changed the high contrast dark blue to the same low
contrast light blue for builtin names, etc. What problem do you think
you are trying to solve by making the doc difficult and even PAINFUL for
me to read?
- a lot more than 1
More contrast was meant in comparison to iteration #1.
It is still subjectively dim enough to me that I could not tell from
memory.
I ran the following experiment: I put old and new versions of the buitin
functions page side-by-side in separate browser windows. I asked my
teenage daughter to come into the room, approach slowly, and say when
she could read one or both windows. At about 5 feet, she could (just)
read the old but not the new.
Do you often read things on your computer monitor from 5ft away?
While I sympathize with the ideal of making the docs readable, particular for
those of us who don't have 20-20 vision, must be readable from halfway across
the room is setting the bar too high. What is important is not *absolute*
readability, but readability relative to the normal use-case of sitting at a
computer under typical reading conditions.
To be honest here, I don't even know which elements you are having trouble
with. I don't see any elements with such low contrast to cause problems at
least not for me. Even with my glasses off, I find the built-in names to be no
less readable as the vanilla text around it. E.g. on this page:
http://www.python.org/~gbrandl/build/html2/library/stdtypes.html
I see built-in names such as `int` and `str` are written as hyperlinks in
medium blue on a white background. When I hover over the link, it becomes a
touch lighter blue, but not enough to appreciably hurt contrast and readability.
I see literals such as `{}` in black on a pale blue-grey background. The
background is faint enough that it is hardly noticeable, not enough to hurt
contrast. So I don't know what you are speaking off when you say the same low
contrast light blue for builtin names, etc. -- can you give an example?
[...]
Using a magnifying glass, the difference seems to be more one of
thickness -- 2 pixel lines versus 1-1.5 pixel lines. I have astigmatism
that is only partly correctable and the residual blurring of
single-pixel lines tends to somewhat mix text color with the background
color.
For what it's worth, it wouldn't surprise me if the problem is the fallback
font. If I'm reading the CSS correctly, the standard font used in the new docs
is Lucinda Grande, with a fallback of Arial. Unfortunately, Lucinda Grande
is normally only available on the Apple Mac, and Arial is a notoriously poor
choice for on-screen text (particularly in smaller text sizes).
http://en.wikipedia.org/wiki/Lucida_Grande
suggests fallbacks of Lucida Sans Unicode, Tahoma, and Verdana. Could they
please be tried before Arial?
E.g. change the font-family from
font-family: 'Lucida Grande',Arial,sans-serif;
to
font-family: 'Lucida Grande','Lucida Sans Unicode','Lucida
Sans',Tahoma,Verdana,Arial,sans-serif;
or similar.
--
Steven
___
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
On Mon, Mar 26, 2012 at 7:42 AM, Terry Reedy tjre...@udel.edu wrote: Can anyone tell me the best way to do that with FireFox? For general webbrowsing, I'm reasonably impressed by the effectiveness of www.readability.com. It's a sign-up service however, and I've never tried it on technical material like the Python docs. 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
Re: [Python-Dev] AUTO: Jon K Peck is out of the office (returning 03/30/2012)
On Sun, Mar 25, 2012 at 05:00, Jon K Peck p...@us.ibm.com wrote: I am out of the office until 03/30/2012. I will be out of the office through Friday, March 30. I expect to have some email access but may be delayed in responding. Note: This is an automated response to your message Python-Dev Digest, Vol 104, Issue 91 sent on 03/25/2012 1:19:50. This is the only notification you will receive while this person is away. Enjoy your vacation. ___ 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
On 3/25/2012 8:37 PM, Steven D'Aprano wrote: E.g. change the font-family from font-family: 'Lucida Grande',Arial,sans-serif; to font-family: 'Lucida Grande','Lucida Sans Unicode','Lucida Sans',Tahoma,Verdana,Arial,sans-serif; or similar. +1 To providing other fallbacks. As Steven says, on my Win7 machine, I do not have 'Lucida Grande' and it wasn't until he mentioned this that I compared the experience of the site with my MacBook (which looks much better!). This machine has both 'Lucida Sans Unicode' and 'Lucida Sans' and it's a toss-up to me which is better -- one is better than the other in certain contexts. Presumably, the character coverage of the Unicode font makes it the superior choice. Personally, I would leave Tahoma out of the list -- the kerning of the font is really aggressive and I find it much harder to read than Verdana. -- 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
On 3/25/2012 8:37 PM, Steven D'Aprano wrote: Terry Reedy wrote: I ran the following experiment: I put old and new versions of the buitin functions page side-by-side in separate browser windows. I asked my teenage daughter to come into the room, approach slowly, and say when she could read one or both windows. At about 5 feet, she could (just) read the old but not the new. The test page I used was the builtin function page in the Library Reference. Do you often read things on your computer monitor from 5ft away? No, I cannot possibly do that. The point is that there *is* a distance for her as well as me at which the old style is clearly more readable than the new. For my daughter, is is 4-5 feet. For me, it is about 2 feet -- with my prescription computer reading glasses. For you, try it and find out. Obviously, most of the people here are more like my daughter than me. I am visually handicapped, and that particular new style is worse for me. And to what purpose? -- 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] PEP 411 - request for pronouncement
On Sat, Mar 24, 2012 at 13:53, Lennart Regebro rege...@gmail.com wrote: On Fri, Mar 23, 2012 at 10:51, Eli Bendersky eli...@gmail.com wrote: 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. I'm not sure what the usecase is for checking in code if a module is provisional or not. It doesn't seem useful, and risks being unmaintained, especially when the flag is on the module itself. Some usecases were given by Jim J. Jewett here: http://mail.python.org/pipermail/python-dev/2012-February/116400.html (and +1-ed by a couple of others.) 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] Playing with a new theme for the docs, iteration 2
On Sun, Mar 25, 2012 at 21:25, Georg Brandl g.bra...@gmx.net 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. Georg, Is there a tracker issue to collect reports about misbehavior of the new theme? Specifically, the sidebar behaves very strangely in the search page. I think it should not be there at all. 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] Playing with a new theme for the docs, iteration 2
On 3/25/2012 8:37 PM, Steven D'Aprano wrote: For what it's worth, it wouldn't surprise me if the problem is the fallback font. If I'm reading the CSS correctly, the standard font used in the new docs is Lucinda Grande, with a fallback of Arial. Unfortunately, Lucinda Grande is normally only available on the Apple Mac, and Arial is a notoriously poor choice for on-screen text (particularly in smaller text sizes). Testing in LibreOffice, I think Ariel may be easier as it has a consistent stroke width, whereas Lucida has thin horizontals. It does look a bit more elegant, though. In any case, Ariel seems to be the basic text font I see in Firefox and Windows help and I have no problem with it. The particular entries I have discussed are class=reference internal There have light serifs. Testing in LibreOffice, it seems to be Courier New. It was previously Courier New 'bold'. I put that in quotes because Courier New is a 'light' font, so that the 'bold' is normal relative to Ariel. In other words, Courier bold matches normal Ariel in stroke weight, so that is looks right mixed in with Ariel, whereas the Courier light is jarring. In a sentence like this returns False; otherwise it returns True. bool is also a class, which is a subclass of int False, True (which use light-weight black rather than light-weight blue Courier), bool, and int all stand out (or stand in) because they have a lighter stroke weight as well as a different (serif versus non-serif) font. These are important words and should not be made to recede into the background as if they were unimportant and optionally skipped. To me, this is backwards and poor design. False,false are marked up like this: tt class=xref docutils literalspan class=preFalse/span/tt bool,in are like so: a class=reference internal href=#int title=int Does the css specify Courier New or is this an unfortunate fallback that might be improved? Perhaps things look better on max/*nix? -- 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, iteration 2
Steven D'Aprano wrote: While I sympathize with the ideal of making the docs readable, particular for those of us who don't have 20-20 vision, must be readable from halfway across the room is setting the bar too high. The point is that reducing contrast never makes anything more readable, and under some conditions it makes things less readable. So the only reason for using less than the maximum available contrast is aesthetics, and whether grey-on-white looks any nicer than black-on-white is very much a matter of opinion. In any case, the aesthetic difference is a very minor one, and you have to ask whether it's really worth compromising on contrast. If I'm reading the CSS correctly, the standard font used in the new docs is Lucinda Grande, with a fallback of Arial. Unfortunately, Lucinda Grande is normally only available on the Apple Mac, and Arial is a notoriously poor choice for on-screen text 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. -- Greg ___ 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
