Re: [Python-Dev] Playing with a new theme for the docs
On 21.03.2012 00:17, R. David Murray wrote: On Tue, 20 Mar 2012 23:38:53 +0100, Georg Brandl g.bra...@gmx.net wrote: Hi all, recently I've grown a bit tired of seeing our default Sphinx theme, especially as so many other projects use it. I decided to play around with something clean this time, and this is the result: http://www.python.org/~gbrandl/build/html/ The font looks better in my browser, but otherwise I prefer the current style. The biggest thing I don't like about the new style is the fact that the content is not set off from the chrome by shading. Having it shaded makes it easier for my eye to ignore it and just focus on the content. Not sure what the unshaded chrome is -- only the header bar, since the sidebar is shaded already? 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 21.03.2012 01:57, Raymond Hettinger wrote: On Mar 20, 2012, at 5:37 PM, Antoine Pitrou wrote: Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: Hi all, recently I've grown a bit tired of seeing our default Sphinx theme, especially as so many other projects use it. I decided to play around with something clean this time, and this is the result: http://www.python.org/~gbrandl/build/html/ Not enough colours, and/or not enough visual cues for page structure. cheers Antoine. Like Antoine, I'm having a hard time navigating the page. For me, the current theme is *much* better. OK, that seems to be the main point people make... let me see if I can come up with a better compromise. 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] GSoC 2012: Python Core Participation?
I'm wondering whether Python Core should participate in GSoC 2012 or not, as core contributors have shown little interest in acting as mentors in the past. If you are a core committer and volunteer as GSoC mentor for 2012, please let me know by Friday (March 23rd). 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
On Wed, Mar 21, 2012 at 07:00, Georg Brandl g.bra...@gmx.net wrote: OK, that seems to be the main point people make... let me see if I can come up with a better compromise. Would it be possible to limit the width of the page? On my 1920px monitor, the lines get awfully long, making them harder to read. Cheers, Dirkjan ___ 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
Turn your monitor portrait or make the window smaller :) ___ 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 21/03/2012 08:25, Dirkjan Ochtman wrote: On Wed, Mar 21, 2012 at 07:00, Georg Brandlg.bra...@gmx.net wrote: OK, that seems to be the main point people make... let me see if I can come up with a better compromise. Would it be possible to limit the width of the page? On my 1920px monitor, the lines get awfully long, making them harder to read. I realise this is bikeshedding by now, but FWIW, please don't. If people want shorter lines, they can narrow their browser, without forcing that preference on the rest of us. Cheers, Dirkjan ___ 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/tartley%40tartley.com -- Jonathan Hartleytart...@tartley.comhttp://tartley.com Made of meat. +44 7737 062 225 twitter/skype: tartley ___ 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 Wed, Mar 21, 2012 at 09:33:13AM +, Jonathan Hartley wrote: On 21/03/2012 08:25, Dirkjan Ochtman wrote: On Wed, Mar 21, 2012 at 07:00, Georg Brandlg.bra...@gmx.net wrote: OK, that seems to be the main point people make... let me see if I can come up with a better compromise. Would it be possible to limit the width of the page? On my 1920px monitor, the lines get awfully long, making them harder to read. I realise this is bikeshedding by now, but FWIW, please don't. If people want shorter lines, they can narrow their browser, without forcing that preference on the rest of us. Seconded. My display is 1920x1200 but I use very large fonts and I'm satisfied with line lengths. 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
Dirkjan Ochtman dirk...@ochtman.nl writes: On Wed, Mar 21, 2012 at 07:00, Georg Brandl g.bra...@gmx.net wrote: OK, that seems to be the main point people make... let me see if I can come up with a better compromise. Would it be possible to limit the width of the page? On my 1920px monitor, the lines get awfully long, making them harder to read. −1. Please, web designers, don't presume to know what width the viewer wants. We can change the window size if that's what we want. -- \ “I hope some animal never bores a hole in my head and lays its | `\ eggs in my brain, because later you might think you're having a | _o__) good idea but it's just eggs hatching.” —Jack Handey | 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
On Tue, 20 Mar 2012 21:39:41 -0400 Terry Reedy tjre...@udel.edu wrote: On 3/20/2012 6:38 PM, Georg Brandl wrote: The current green on the front page is too heavy. Green? hmm... you mean blue, right? :) 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
On Tue, 20 Mar 2012 21:58:57 -0400 Ned Batchelder n...@nedbatchelder.com wrote: On 3/20/2012 6:38 PM, Georg Brandl wrote: Let me know what you think, or play around and send some improvements. (The collapsible sidebar is not adapted to it yet, but will definitely be integrated before I consider applying a new theme to the real docs.) Not to add to the chorus of tweakers, but if I could change just one thing about the current theme, it would be to remove full justification of the text. Ow, I hate non-justified text myself :( Bikeshedding 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
On 21/03/2012 09:33, Jonathan Hartley wrote: On 21/03/2012 08:25, Dirkjan Ochtman wrote: On Wed, Mar 21, 2012 at 07:00, Georg Brandlg.bra...@gmx.net wrote: OK, that seems to be the main point people make... let me see if I can come up with a better compromise. Would it be possible to limit the width of the page? On my 1920px monitor, the lines get awfully long, making them harder to read. I realise this is bikeshedding by now, but FWIW, please don't. If people want shorter lines, they can narrow their browser, without forcing that preference on the rest of us. + sys.maxint Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 3/21/2012 6:16 AM, Oleg Broytman wrote: On Wed, Mar 21, 2012 at 09:33:13AM +, Jonathan Hartley wrote: On 21/03/2012 08:25, Dirkjan Ochtman wrote: On Wed, Mar 21, 2012 at 07:00, Georg Brandlg.bra...@gmx.net wrote: OK, that seems to be the main point people make... let me see if I can come up with a better compromise. Would it be possible to limit the width of the page? On my 1920px monitor, the lines get awfully long, making them harder to read. I realise this is bikeshedding by now, but FWIW, please don't. If people want shorter lines, they can narrow their browser, without forcing that preference on the rest of us. Seconded. My display is 1920x1200 but I use very large fonts and I'm satisfied with line lengths. The best thing to do is to set a max-width in ems, say 50em. This leaves the text at a reasonable width, but adapts naturally for people with larger fonts. --Ned. Oleg. ___ 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 Wed, 21 Mar 2012 06:58:21 +0100, Georg Brandl g.bra...@gmx.net wrote: On 21.03.2012 00:17, R. David Murray wrote: On Tue, 20 Mar 2012 23:38:53 +0100, Georg Brandl g.bra...@gmx.net wrote: Hi all, recently I've grown a bit tired of seeing our default Sphinx theme, especially as so many other projects use it. I decided to play around with something clean this time, and this is the result: http://www.python.org/~gbrandl/build/html/ The font looks better in my browser, but otherwise I prefer the current style. The biggest thing I don't like about the new style is the fact that the content is not set off from the chrome by shading. Having it shaded makes it easier for my eye to ignore it and just focus on the content. Not sure what the unshaded chrome is -- only the header bar, since the sidebar is shaded already? Header bar and footer. But I also like the fact that the current site shades the sidebar all the way down (and darker, though obviously we have contrast issues from some folks that don't bother me). Otherwise that whitespace on the left just looks...wrong. But that last is considerably less important. --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
21.03.12 14:38, Ned Batchelder написав(ла): The best thing to do is to set a max-width in ems, say 50em. This leaves the text at a reasonable width, but adapts naturally for people with larger fonts. It's good for books, magazines, and newspapers, but not for technical site. ;) ___ 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 405 (built-in virtualenv) status
-Original Message- From: Carl Meyer [mailto:c...@oddbird.net] Sent: 19. mars 2012 19:19 To: Kristján Valur Jónsson Cc: Python-Dev (python-dev@python.org) Subject: Re: [Python-Dev] PEP 405 (built-in virtualenv) status Hello Kristján, I think there's one important (albeit odd and magical) bit of Python's current behavior that you are missing in your blog post. All of the initial sys.path directories are constructed relative to sys.prefix and sys.exec_prefix, and those values in turn are determined (if PYTHONHOME is not set), by walking up the filesystem tree from the location of the Python binary, looking for the existence of a file at the relative path lib/pythonX.X/os.py (or Lib/os.py on Windows). Python takes the existence of this file to mean that it's found the standard library, and sets sys.prefix accordingly. Thus, you can achieve reliable full isolation from any installed Python, with no need for environment variables, simply by placing a file (it can even be empty) at that relative location from the location of your Python binary. You will still get some default paths added on sys.path, but they will all be relative to your Python binary and thus presumably under your control; nothing from any other location will be on sys.path. I doubt you will find this solution satisfyingly elegant, but you might nonetheless find it practically useful. Right. Thanks for explaining this. Although, it would appear that Python also has a mechanism for detecting that it is being run from a build environment and ignore PYTHONHOME in that case too. Beyond that possible tweak, while I certainly wouldn't oppose any effort to clean up / document / make-optional Python's startup sys.path-setting behavior, I think it's mostly orthogonal to PEP 405, and I don't think it would be helpful to expand the scope of PEP 405 to include that effort. Well, it sounds as this pep can definitely be used as the basis for work to completely customize the startup behaviour. In my case, it would be desirable to be able to completely ignore any PYTHONHOME environment variable (and any others). I'd also like to be able to manually set up the sys.path. Perhaps if we can set things up that one key (ignore_env) will cause the environment variables to be ignored, and then, an empty home key will set the sys.path to point to the directory of the .cfg file. Presumably, this would then cause a site.py found at that place to be executed and one could code whatever extra logic one wants into that file. Possibly a site key in the .cfg file would achieve the same goal, allowing the user to call this setup file whatever he wants. With something like this in place, the built in behaviour of python.exe to realize that it is running from a build environment and in that case ignore PYTHONPATH and set a special sys.path, could all be removed from being hardcoded into being coded into some buildsite.py in the cpython root folder. Kristján ___ 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
21.03.12 03:58, Ned Batchelder написав(ла):
Books, magazines, and newspapers look good with full justification, web
pages do not. Can we switch to left-justified instead?
You can add line
p {text-align: left !important}
to your browser custom stylesheet.
If you are using Firefox or Chrome (Chromium), for them there are
extensions (Stylish) that allow to apply the style to the particular site.
___
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 3/21/2012 9:44 AM, Serhiy Storchaka wrote:
21.03.12 03:58, Ned Batchelder написав(ла):
Books, magazines, and newspapers look good with full justification, web
pages do not. Can we switch to left-justified instead?
You can add line
p {text-align: left !important}
to your browser custom stylesheet.
If you are using Firefox or Chrome (Chromium), for them there are
extensions (Stylish) that allow to apply the style to the particular
site.
Any of the tweaks people are suggesting could be applied individually
using this technique. We could just as easily choose to make the site
left-justified, and let the full-justification fans use custom
stylesheets to get it.
The challenge for the maintainer of the docs site is to choose a good
design that most people will see. We're bound to disagree on what that
design should be, and I suggest that probably none of us are designer
enough to come up with the best one. Perhaps we could find an
interested designer to help?
--Ned.
___
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] Python install layout and the PATH on win32
Mark, MAL, Martin, Tarek, Could you comment on this? This is in the context of changing the name of the 'Scripts' directory on windows to 'bin'. Éric brings up the point (explained more below) that if we make this change, packages made/installed the new packaging infrastructure and those made/installed with bdist_winist and the old (frozen) distutils will be inconsistent. The reason why is that the old distutils has a hard-coded dict in distutils.command.install that would point to the old locations. If we were to make this change in sysconfig.cfg, we would probably want to make a corresponding change in the INSTALL_SCHEMES dict in distutils.command.install. More context: On 3/20/2012 10:41 PM, Éric Araujo wrote: Le 20/03/2012 21:40, VanL a écrit : On Tuesday, March 20, 2012 at 5:07 PM, Paul Moore wrote: It's worth remembering Éric's point - distutils is frozen and changes are in theory not allowed. This part of the proposal is not possible without an exception to that ruling. Personally, I don't see how making this change could be a problem, but I'm definitely not an expert. If distutils doesn't change, bdist_wininst installers built using distutils rather than packaging will do the wrong thing with regard to this change. End users won't be able to tell how an installer has been built. Looking at the code in bdist_wininst, it loops over the keys in the INSTALL_SCHEMES dict to find the correct locations. If the hard-coded dict were changed, then the installer would 'just work' with the right location - and this matches my experience having made this sort of change. When I change the INSTALL_SCHEMES dict, things get installed according to the new scheme without difficulty using the standard tools. The only time when something is trouble is if it does its own install routine and hard-codes 'Scripts' as the name of the install directory - and I have only seen that in PyPM a couple versions ago. From the top of my head the developers with the most experience about Windows deployment are Martin v. Löwis, Mark Hammond and Marc-André Lemburg (not sure about the Windows part for MAL, but he maintains a library that extends distutils and has been broken in the past). I think their approval is required for this kind of huge change. Note the above - this is why I would like your comment. The point of the distutils freeze (i.e. feature moratorium) is that we just can’t know what complicated things people are doing with undocumented internals, because distutils appeared unmaintained and under-documented for years and people had to work with and around it; since the start of the distutils2 project we can Just Say No™ to improvements and features in distutils. “I don’t see what could possibly go wrong” is a classic line in both horror movies and distutils developmentwink. Renaming Scripts to bin on Windows would have effects on some tools we know and surely on many tools we don’t know. We don’t want to see again people who use or extend distutils come with torches and pitchforks because internals were changed and we have to revert. So in my opinion, to decide to go ahead with the change we need strong +1s from the developers I named above and an endorsement by Tarek, or if he can’t participate in the discussion, Guido. As a footnote, distutils is already broken in 3.3. Now we give users or system administrators the possibility to edit the install schemes at will in sysconfig.cfg, but distutils hard-codes the old scheme. I tend to think it should be fixed, to make the distutils-packaging transition/cohabitation possible. Any comment? Thanks, Van CIRCULAR 230 NOTICE: To ensure compliance with requirements imposed by U.S. Treasury Regulations, Haynes and Boone, LLP informs you that any U.S. tax advice contained in this communication (including any attachments) was not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. CONFIDENTIALITY NOTICE: This electronic mail transmission is confidential, may be privileged and should be read or retained only by the intended recipient. If you have received this transmission in error, please immediately notify the sender and delete it from your system. ___ 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
Lindberg, Van wrote: Mark, MAL, Martin, Tarek, Could you comment on this? This is in the context of changing the name of the 'Scripts' directory on windows to 'bin'. Éric brings up the point (explained more below) that if we make this change, packages made/installed the new packaging infrastructure and those made/installed with bdist_winist and the old (frozen) distutils will be inconsistent. The reason why is that the old distutils has a hard-coded dict in distutils.command.install that would point to the old locations. If we were to make this change in sysconfig.cfg, we would probably want to make a corresponding change in the INSTALL_SCHEMES dict in distutils.command.install. I'm not sure I understand the point in making that change. Could you expand on the advantage of using bin instead of Scripts ? Note that distutils just provides defaults for these installation locations. All of them can be overridden using command line arguments to the install command. FWIW: I've dropped support for bdist_wininst in mxSetup.py since bdist_msi provides much better system integration. More context: On 3/20/2012 10:41 PM, Éric Araujo wrote: Le 20/03/2012 21:40, VanL a écrit : On Tuesday, March 20, 2012 at 5:07 PM, Paul Moore wrote: It's worth remembering Éric's point - distutils is frozen and changes are in theory not allowed. This part of the proposal is not possible without an exception to that ruling. Personally, I don't see how making this change could be a problem, but I'm definitely not an expert. If distutils doesn't change, bdist_wininst installers built using distutils rather than packaging will do the wrong thing with regard to this change. End users won't be able to tell how an installer has been built. Looking at the code in bdist_wininst, it loops over the keys in the INSTALL_SCHEMES dict to find the correct locations. If the hard-coded dict were changed, then the installer would 'just work' with the right location - and this matches my experience having made this sort of change. When I change the INSTALL_SCHEMES dict, things get installed according to the new scheme without difficulty using the standard tools. The only time when something is trouble is if it does its own install routine and hard-codes 'Scripts' as the name of the install directory - and I have only seen that in PyPM a couple versions ago. From the top of my head the developers with the most experience about Windows deployment are Martin v. Löwis, Mark Hammond and Marc-André Lemburg (not sure about the Windows part for MAL, but he maintains a library that extends distutils and has been broken in the past). I think their approval is required for this kind of huge change. Note the above - this is why I would like your comment. The point of the distutils freeze (i.e. feature moratorium) is that we just can’t know what complicated things people are doing with undocumented internals, because distutils appeared unmaintained and under-documented for years and people had to work with and around it; since the start of the distutils2 project we can Just Say No™ to improvements and features in distutils. “I don’t see what could possibly go wrong” is a classic line in both horror movies and distutils developmentwink. Renaming Scripts to bin on Windows would have effects on some tools we know and surely on many tools we don’t know. We don’t want to see again people who use or extend distutils come with torches and pitchforks because internals were changed and we have to revert. So in my opinion, to decide to go ahead with the change we need strong +1s from the developers I named above and an endorsement by Tarek, or if he can’t participate in the discussion, Guido. As a footnote, distutils is already broken in 3.3. Now we give users or system administrators the possibility to edit the install schemes at will in sysconfig.cfg, but distutils hard-codes the old scheme. I tend to think it should be fixed, to make the distutils-packaging transition/cohabitation possible. Any comment? Thanks, Van CIRCULAR 230 NOTICE: To ensure compliance with requirements imposed by U.S. Treasury Regulations, Haynes and Boone, LLP informs you that any U.S. tax advice contained in this communication (including any attachments) was not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. CONFIDENTIALITY NOTICE: This electronic mail transmission is confidential, may be privileged and should be read or retained only by the intended recipient. If you have received this transmission in error, please immediately notify the sender and delete it from your system. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar
Re: [Python-Dev] Playing with a new theme for the docs
On 21 March 2012 13:38, Ned Batchelder n...@nedbatchelder.com wrote: On 3/21/2012 6:16 AM, Oleg Broytman wrote: On Wed, Mar 21, 2012 at 09:33:13AM +, Jonathan Hartley wrote: On 21/03/2012 08:25, Dirkjan Ochtman wrote: On Wed, Mar 21, 2012 at 07:00, Georg Brandlg.bra...@gmx.net wrote: OK, that seems to be the main point people make... let me see if I can come up with a better compromise. Would it be possible to limit the width of the page? On my 1920px monitor, the lines get awfully long, making them harder to read. I realise this is bikeshedding by now, but FWIW, please don't. If people want shorter lines, they can narrow their browser, without forcing that preference on the rest of us. Seconded. My display is 1920x1200 but I use very large fonts and I'm satisfied with line lengths. The best thing to do is to set a max-width in ems, say 50em. This leaves the text at a reasonable width, but adapts naturally for people with larger fonts. --Ned. FYI, the current paragraph font size on docs.python.org is 16px, while for http://www.python.org/~gbrandl/build/html/ it's 13px, so increasing that should help readability :) You can use @media queries to adjust it to screen resolution, which should solve the problem with long lines. -- Łukasz Rekucki ___ 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
21.03.12 16:18, Ned Batchelder написав(ла): We could just as easily choose to make the site left-justified, and let the full-justification fans use custom stylesheets to get it. I find justified text convenient and pleasant for the eyes. Many people hate left-aligned text. I think that the best would be the use of left-aligned text at the small width of the window (640px and less), when they become obvious drawbacks of justified text, and use justified text with a large width. Perhaps we could find an interested designer to help? Isn't Georg Brandl a designer? The proposed design looks professional for me and is not worse than the design of large corporations (though there are some defects). The current design is also very good. Optimum is, I suppose, in the middle. ___ 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 2012-03-21, at 11:06 AM, Łukasz Rekucki wrote: FYI, the current paragraph font size on docs.python.org is 16px, while for http://www.python.org/~gbrandl/build/html/ it's 13px, so increasing that should help readability :) You can use @media queries to adjust it to screen resolution, which should solve the problem with long lines. +1. It's much harder to read text in the new design. I would also make links a bit darker. - Yury ___ 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 Mar 21, 2012 5:44 AM, Ned Batchelder n...@nedbatchelder.com wrote: The best thing to do is to set a max-width in ems, say 50em. This leaves the text at a reasonable width, but adapts naturally for people with larger fonts. Please, no, not even this improved version of coddling. If you're formatting e.g. a newspaper or a book, by all means (though I still think the user should be given ultimate control -- and I don't mean editing the CSS using the browser's development tools :-). But when reading docs there are all sorts of reasons why I might want to stretch the window to maximum width and nothing's more frustrating than a website that forces clipping, folding or a horizontal scroll bar even when I make the window wide enough. And sometimes I just don't care that much about reading the text, but having more things visible at once (vertically) is worth it. (Can you see why I invented a whitespace-sensitive language? I have a whitespace-sensitive brain. :-) -- --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] Playing with a new theme for the docs
On Tue, Mar 20, 2012 at 11:38:53PM +0100, Georg Brandl wrote: recently I've grown a bit tired of seeing our default Sphinx theme, especially as so many other projects use it. I decided to play around with something clean this time, and this is the result: http://www.python.org/~gbrandl/build/html/ Looks very nice! A few notes, if you don't mind. 1. I'd prefer a little bit bigger fonts. 2. IWBN IMHO to extend the grayish background of the navigation bar at the left to the bottom of the page. White space below short boxes looks strange for me. 3. A lot of small adjacent code snippets with a different background make my eyes hurt. See for example the note number 5 at http://www.python.org/~gbrandl/build/html/library/stdtypes.html#sequence-types-str-bytes-bytearray-list-tuple-range I'd like inline code snippets to have the same background. Bold font and/or a different foreground color would be better, in my opinion. 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
On Wed, Mar 21, 2012 at 7:18 AM, Ned Batchelder n...@nedbatchelder.com wrote: The challenge for the maintainer of the docs site is to choose a good design that most people will see. We're bound to disagree on what that design should be, and I suggest that probably none of us are designer enough to come up with the best one. Perhaps we could find an interested designer to help? I've come to the conclusion that good design is not so much a matter of finding the best of anything (font, spacing rules, colors, icons, artowork, etc.). Good design is highly subjective to fashion, and the people who are recognized to be the best designers are more often than not just those with a strong enough opinion to push their creative ideas through. Then other designers, who are not quite as good but still have a nose for the latest fashion, copy their ideas and for a while anything that hasn't been redesigned looks old-fashioned. (Before you say something about limitations of old technology, note how often designers go back to older styles and manage to make them look fashionable again.) If you want something that attracts attention through controversy, get one of those initial thought leaders. If you want something that looks current today but which will probably be out of style next year, use one of the style-following designers. If you want something that is maximally useful, get a scientist with an ounce of style sense to do your design... Oh hey, Georg *is* a scientist! And he's got more than an ounce of style. So just let him do it and let's not try to micromanage things. (I had to speak up about the low contrast because Georg has young eyes and may not realize that this issue exists for older Pythonistas.) -- --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] Playing with a new theme for the docs
If I can get my five cents, I will tell about my impressions. I really liked the background of allocated blocks (such as notes and code snippets) has become less diverse (but still visible). The border around these blocks have become more accurate and more pleasant to emphasize blocks. It is very good that the sidebar is no longer confused look. And everything looks quite nice. But the font is a little bit small for my eyes (on the contrary current theme font a little bit big). This leads to too long (in characters) lines. Less obvious was the structure of the document (due to decrease the font size of the header and the removal of the dividing lines). I would like to that the background color of .note tt has become a little lighter and quieter. ___ 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
21.03.12 18:00, Guido van Rossum написав(ла): (Can you see why I invented a whitespace-sensitive language? I have a whitespace-sensitive brain. :-) It should be added to favorite quotes. ___ 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 3/21/2012 7:09 AM, Antoine Pitrou wrote: On Tue, 20 Mar 2012 21:39:41 -0400 Terry Reedytjre...@udel.edu wrote: On 3/20/2012 6:38 PM, Georg Brandl wrote: The current green on the front page is too heavy. Green? hmm... you mean blue, right? :) Yeh, a muddy slightly greenish blue. I would prefer what I call a real blue, as in the logo, or the quoted text above on Thunderbird. -- 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
On 3/21/2012 1:04 PM, Serhiy Storchaka wrote: If I can get my five cents, I will tell about my impressions. I really liked the background of allocated blocks (such as notes and code snippets) has become less diverse (but still visible). The border around these blocks have become more accurate and more pleasant to emphasize blocks. It is very good that the sidebar is no longer confused look. And everything looks quite nice. But the font is a little bit small for my eyes (on the contrary current theme font a little bit big). This leads to too long (in characters) lines. Less obvious was the structure of the document (due to decrease the font size of the header and the removal of the dividing lines). You can use Ctrl-+ to increase the size of the text, and modern browsers remember that for the next time you visit the site. --Ned. I would like to that the background color of .note tt has become a little lighter and quieter. ___ 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
On Wed, Mar 21, 2012 at 11:40 AM, Ned Batchelder n...@nedbatchelder.com wrote: You can use Ctrl-+ to increase the size of the text, and modern browsers remember that for the next time you visit the site. That doesn't mean the web designer shouldn't think at least twice before specifying a smaller font than the browser default. -- --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] Playing with a new theme for the docs
On Wed, Mar 21, 2012 at 2:46 PM, Guido van Rossum gu...@python.org wrote: That doesn't mean the web designer shouldn't think at least twice before specifying a smaller font than the browser default. Yet 90% of designers (or more) insist on making text insanely small, commonly specifying the size in pixles or (if we're lucky) points. Not sure there's any lesson to be learned from this, aside from designers really having it out for anyone who needs to read. -Fred -- Fred L. Drake, Jr. fdrake at acm.org A person who won't read has no advantage over one who can't read. --Samuel Langhorne Clemens ___ 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 Wed, Mar 21, 2012 at 02:40:04PM -0400, Ned Batchelder wrote: You can use Ctrl-+ to increase the size of the text, and modern browsers remember that for the next time you visit the site. Browsers usually remember the setting for the entire site, not only documentation. 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
On 3/21/2012 2:46 PM, Guido van Rossum wrote: On Wed, Mar 21, 2012 at 11:40 AM, Ned Batcheldern...@nedbatchelder.com wrote: You can use Ctrl-+ to increase the size of the text, and modern browsers remember that for the next time you visit the site. That doesn't mean the web designer shouldn't think at least twice before specifying a smaller font than the browser default. Yes, sorry, that was exactly my point earlier in this thread. I was being a bit snarky with Serhiy. Seems the standard here is for people to request their personal favorite tweaks, and then tell others that they can use browser customizations to get what they want. Guido, you encouraged us to use science, but only after describing my science-based maximum line-length suggestion as coddling, then said we should let Georg get on with it, but only after reiterating your personal favorite tweak (which I happen to agree with). There's no way a committee (which this thread effectively is) will come up with a good design. Everyone will dislike something about it. I think it would be interesting to use the power of the web to provide docs whose style could be adjusted a few ways to make people happy, but that is probably more than anyone is willing to volunteer for, I know I can't step up to do it. Personally, I think two Python projects that have focused on docs and done a good job of it are Django and readthedocs.org. Perhaps we could follow their lead? --Ned. ___ 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 3/21/2012 3:06 PM, Fred Drake wrote: On Wed, Mar 21, 2012 at 2:46 PM, Guido van Rossumgu...@python.org wrote: That doesn't mean the web designer shouldn't think at least twice before specifying a smaller font than the browser default. Yet 90% of designers (or more) insist on making text insanely small, commonly specifying the size in pixles or (if we're lucky) points. Not sure there's any lesson to be learned from this, aside from designers really having it out for anyone who needs to read. There are bad designers, or more to the point, designers who favor the overall look of the page at the expense of the utility of the page. That doesn't mean all designers are bad, or that design is bad. Don't throw out the baby with the bathwater. --Ned. -Fred ___ 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 Mar 21, 2012 12:00 PM, Guido van Rossum gu...@python.org wrote: On Mar 21, 2012 5:44 AM, Ned Batchelder n...@nedbatchelder.com wrote: The best thing to do is to set a max-width in ems, say 50em. This leaves the text at a reasonable width, but adapts naturally for people with larger fonts. Please, no, not even this improved version of coddling. If you're formatting e.g. a newspaper or a book, by all means (though I still think the user should be given ultimate control -- and I don't mean editing the CSS using the browser's development tools :-). But when reading docs there are all sorts of reasons why I might want to stretch the window to maximum width and nothing's more frustrating than a website that forces clipping, folding or a horizontal scroll bar even when I make the window wide enough. Well, the only thing that's more frustrating than that is having to resize my window to make the text readable, and then *still* having to scroll horizontally for the wide bits, or have to alternate sizes of the window. Just because flowing text paragraphs are set to a moderate max-width, that doesn't mean that code samples, tables, etc. all have to be the *same* max-width, or have any max-width at all. That is, keeping flowing text readable is not incompatible with having arbitrarily-wide code, tables, etc. (Text width is an ergonomic consideration as much as font size and color: too wide in absolute characters, and the eye has to hunt up and down to find where to start reading the next line.) ___ 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 Wed, Mar 21, 2012 at 12:12 PM, Ned Batchelder n...@nedbatchelder.com wrote: On 3/21/2012 2:46 PM, Guido van Rossum wrote: On Wed, Mar 21, 2012 at 11:40 AM, Ned Batcheldern...@nedbatchelder.com wrote: You can use Ctrl-+ to increase the size of the text, and modern browsers remember that for the next time you visit the site. That doesn't mean the web designer shouldn't think at least twice before specifying a smaller font than the browser default. Yes, sorry, that was exactly my point earlier in this thread. I was being a bit snarky with Serhiy. Seems the standard here is for people to request their personal favorite tweaks, and then tell others that they can use browser customizations to get what they want. Guido, you encouraged us to use science, but only after describing my science-based maximum line-length suggestion as coddling, then said we should let Georg get on with it, but only after reiterating your personal favorite tweak (which I happen to agree with). I have a fair number of strong usability gripes about current (and past :-) design trends, but I know I can't design a decent looking website myself if my life depended on it. There's no way a committee (which this thread effectively is) will come up with a good design. Everyone will dislike something about it. I think it would be interesting to use the power of the web to provide docs whose style could be adjusted a few ways to make people happy, but that is probably more than anyone is willing to volunteer for, I know I can't step up to do it. I think it's fine to have a bunch of folks submit their pet peeves (and argue them to the death :-) to the design czar and then let the czar (i.e. Georg) decide. Personally, I think two Python projects that have focused on docs and done a good job of it are Django and readthedocs.org. Perhaps we could follow their lead? I think they are actually more trend-followers,and they seem to make a bunch of the mistakes I've fulminated against here. But again, I'll leave it to Georg. -- --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] Playing with a new theme for the docs
On 3/21/2012 3:45 PM, Ethan Furman wrote: Guido van Rossum wrote: On Wed, Mar 21, 2012 at 7:18 AM, Ned Batchelder n...@nedbatchelder.com wrote: The challenge for the maintainer of the docs site is to choose a good design that most people will see. We're bound to disagree on what that design should be, and I suggest that probably none of us are designer enough to come up with the best one. Perhaps we could find an interested designer to help? I've come to the conclusion that good design is not so much a matter of finding the best of anything (font, spacing rules, colors, icons, artowork, etc.). Good design is highly subjective to fashion, and the people who are recognized to be the best designers are more often than not just those with a strong enough opinion to push their creative ideas through. Then other designers, who are not quite as good but still have a nose for the latest fashion, copy their ideas and for a while anything that hasn't been redesigned looks old-fashioned. (Before you say something about limitations of old technology, note how often designers go back to older styles and manage to make them look fashionable again.) If you want something that attracts attention through controversy, get one of those initial thought leaders. If you want something that looks current today but which will probably be out of style next year, use one of the style-following designers. If you want something that is maximally useful, get a scientist with an ounce of style sense to do your design... Oh hey, Georg *is* a scientist! And he's got more than an ounce of style. So just let him do it and let's not try to micromanage things. (I had to speak up about the low contrast because Georg has young eyes and may not realize that this issue exists for older Pythonistas.) +1000 Deriding the entire discipline of design because some of its practitioners are hacks is like pointing at PHP kiddies as the reason why you don't need software architects. Yes, we could make the mistake of over-designing it, and that would be a mistake. The science you seek is something that designers are well-versed in. --Ned. ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/21/2012 03:13 PM, Ned Batchelder wrote: On 3/21/2012 3:06 PM, Fred Drake wrote: On Wed, Mar 21, 2012 at 2:46 PM, Guido van Rossumgu...@python.org wrote: That doesn't mean the web designer shouldn't think at least twice before specifying a smaller font than the browser default. Yet 90% of designers (or more) insist on making text insanely small, commonly specifying the size in pixles or (if we're lucky) points. Not sure there's any lesson to be learned from this, aside from designers really having it out for anyone who needs to read. There are bad designers, or more to the point, designers who favor the overall look of the page at the expense of the utility of the page. That doesn't mean all designers are bad, or that design is bad. Don't throw out the baby with the bathwater. Designers who care more about utility / accessibility more than their hipster karma seem to be a tiny minority in the current web world (without even counting web designers who think a Photoshop document is the final deliverable). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9qPBEACgkQ+gerLs4ltQ5fMwCcD8cHLDch/cIlBpVY4htmlDN4 fzQAmgNUVVn+uByZRBI22TB7ETdkLzmP =ZHdF -END PGP 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
Guido van Rossum wrote: On Wed, Mar 21, 2012 at 7:18 AM, Ned Batchelder n...@nedbatchelder.com wrote: The challenge for the maintainer of the docs site is to choose a good design that most people will see. We're bound to disagree on what that design should be, and I suggest that probably none of us are designer enough to come up with the best one. Perhaps we could find an interested designer to help? I've come to the conclusion that good design is not so much a matter of finding the best of anything (font, spacing rules, colors, icons, artowork, etc.). Good design is highly subjective to fashion, and the people who are recognized to be the best designers are more often than not just those with a strong enough opinion to push their creative ideas through. Then other designers, who are not quite as good but still have a nose for the latest fashion, copy their ideas and for a while anything that hasn't been redesigned looks old-fashioned. (Before you say something about limitations of old technology, note how often designers go back to older styles and manage to make them look fashionable again.) If you want something that attracts attention through controversy, get one of those initial thought leaders. If you want something that looks current today but which will probably be out of style next year, use one of the style-following designers. If you want something that is maximally useful, get a scientist with an ounce of style sense to do your design... Oh hey, Georg *is* a scientist! And he's got more than an ounce of style. So just let him do it and let's not try to micromanage things. (I had to speak up about the low contrast because Georg has young eyes and may not realize that this issue exists for older Pythonistas.) +1000 ___ 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 Wed, Mar 21, 2012 at 3:13 PM, Ned Batchelder n...@nedbatchelder.com wrote: There are bad designers, or more to the point, designers who favor the overall look of the page at the expense of the utility of the page. That doesn't mean all designers are bad, or that design is bad. Don't throw out the baby with the bathwater. I get that. I'm not bad-mouthing actual design, and there are definitely good designers out there. It's unfortunate they're so seriously outnumbered. -Fred -- Fred L. Drake, Jr. fdrake at acm.org A person who won't read has no advantage over one who can't read. --Samuel Langhorne Clemens ___ 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 3/21/2012 4:38 PM, Fred Drake wrote: On Wed, Mar 21, 2012 at 3:13 PM, Ned Batcheldern...@nedbatchelder.com wrote: There are bad designers, or more to the point, designers who favor the overall look of the page at the expense of the utility of the page. That doesn't mean all designers are bad, or that design is bad. Don't throw out the baby with the bathwater. I get that. I'm not bad-mouthing actual design, and there are definitely good designers out there. It's unfortunate they're so seriously outnumbered. Yeah, just like software architects... :-( --Ned. -Fred ___ 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 Wed, 21 Mar 2012 12:39:18 -0700, Guido van Rossum gu...@python.org wrote: On Wed, Mar 21, 2012 at 12:12 PM, Ned Batchelder n...@nedbatchelder.com wrote: Personally, I think two Python projects that have focused on docs and done a good job of it are Django and readthedocs.org. Â Perhaps we could follow their lead? I think they are actually more trend-followers,and they seem to make a bunch of the mistakes I've fulminated against here. But again, I'll leave it to Georg. I'm pretty sure they are following the trend set by Python/Georg...it comes withs Sphinx, after all, and looks pretty good in general. --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] Issue 13524: subprocess on Windows
I tripped over this one trying to make one of our Python at work Windows compatible. We had no idea that a magic 'SystemRoot' environment variable would be required, and it was causing issues for pyzmq. It might be nice to reflect the findings of this email thread on the subprocess documentation page: http://docs.python.org/library/subprocess.html Currently the docs mention this: Note If specified, env must provide any variables required for the program to execute. On Windows, in order to run a side-by-side assembly the specified env must include a valid SystemRoot. How about rewording that to: Note If specified, env must provide any variables required for the program to execute. On Windows, a valid SystemRoot environment variable is required for some Python libraries such as the 'random' module. Also, in order to run a side-by-side assembly the specified env must include a valid SystemRoot. ___ 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
http://hg.python.org/cpython/rev/730d5357 changeset: 75850:730d5357 user: Stefan Krah sk...@bytereef.org date: Wed Mar 21 18:25:23 2012 +0100 summary: Issue #7652: Integrate the decimal floating point libmpdec library to speed up the decimal module. Performance gains of the new C implementation are between 12x and 80x, depending on the application. Congrats Stefan! And thanks for the huge chunk of code. 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
Ned Batchelder wrote: Any of the tweaks people are suggesting could be applied individually using this technique. We could just as easily choose to make the site left-justified, and let the full-justification fans use custom stylesheets to get it. Is it really necessary for the site to specify the justification at all? Why not leave it to the browser and whatever customisation the user chooses to make? -- 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
Re: [Python-Dev] Python install layout and the PATH on win32
On 22/03/2012 1:22 AM, Lindberg, Van wrote: Mark, MAL, Martin, Tarek, Could you comment on this? Eric is correct - tools will be broken by this change. However, people seem willing to push forward on this and accept such breakage as the necessary cost. MAL, in his followup, asks what the advantages are of such a change. I've actually been asking for the same thing in this thread and the only real answer I've got is consistency. So while I share MAL's concerns, people seem willing to push forward on this anyway, without the benefits having been explained. IOW, this isn't the decision I would make, but I think I've already made that point a number of times in this thread. Beyond that, there doesn't seem much for me to add... Mark ___ 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
+10 for new design.
+1 for respecting default font size rather than div.body {font-size: smaller;}
Users loving smaller font can set their browser's default font size.
On Wed, Mar 21, 2012 at 7:38 AM, Georg Brandl g.bra...@gmx.net wrote:
Hi all,
recently I've grown a bit tired of seeing our default Sphinx theme,
especially as so many other projects use it. I decided to play around
with something clean this time, and this is the result:
http://www.python.org/~gbrandl/build/html/
The corresponding sandbox repo is at
http://hg.python.org/sandbox/doc-theme/#doc-theme
Let me know what you think, or play around and send some improvements.
(The collapsible sidebar is not adapted to it yet, but will definitely
be integrated before I consider applying a new theme to the real docs.)
Thanks,
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/songofacandy%40gmail.com
--
INADA Naoki songofaca...@gmail.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] Python install layout and the PATH on win32
On 21 March 2012 22:43, Mark Hammond skippy.hamm...@gmail.com wrote: On 22/03/2012 1:22 AM, Lindberg, Van wrote: Mark, MAL, Martin, Tarek, Could you comment on this? Eric is correct - tools will be broken by this change. However, people seem willing to push forward on this and accept such breakage as the necessary cost. MAL, in his followup, asks what the advantages are of such a change. I've actually been asking for the same thing in this thread and the only real answer I've got is consistency. So while I share MAL's concerns, people seem willing to push forward on this anyway, without the benefits having been explained. IOW, this isn't the decision I would make, but I think I've already made that point a number of times in this thread. Beyond that, there doesn't seem much for me to add... I agree on all points here. I don't understand quite why backward compatibility is being treated so lightly here. But equally, I've made my points and have little further to add. One thought though - maybe this should need a PEP at least, to document the proposal and record the various arguments made in this thread? 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
[Python-Dev] New PEP
*Hi, I am a graduating Berkeley student that loves python and would like to propose an enhancement to python. My proposal introduces a concept of slicing generator. For instance, if one does x[:] it returns a list which is a copy of x. Sometimes programmers would want to iterate over a slice of x, but they do not like the overhead of constructing another list. Instead we can create a similar operator that returns a generator. My proposed syntax is x(:). The programmers are of course able to set lower, upper, and step size like the following. x(1::-1) This would make code much cleaner in a lot of instances, one example lets say we have a very large list x and we want to sum all the numbers but the last 20, and we only want to loop through the even indices. We would have to do something like this. sum(x[:-20:2]) or we can do a workaround to save space for time and do something like this. sum( value for i, value in enumerate(x) if i -20 and not i % 2 ) But with my proposal we are able do the following. sum(x(:-20:2)) Which affords space without sacrificing expressiveness. For another example lets say we have a problem that we want to check a condition is true for every pairwise element in a list x. def allfriends(x): for i in range(len(x)): for j in range(i+1, len(x)): if not friends(x[i], x[j]): return False return True A more pythonic way is to actually loop through the values instead of the indices like this. def allfriends(x): for i, a in enumerate(x): for j, b in enumerate(x[i+1:]): if not friends(a, b): return False return True This however bring a lot of overhead because we have to construct a new list for every slice call. With my proposal we are able to do this. def allfriends(x): for i, a in enumerate(x): for j, b in enumerate(x(i+1:)): if not friends(a, b): return False return True This proposal however goes against one heuristic in the zen of python, namely “Special cases aren’t special enough to break the rules.” The way that the proposal breaks this rule is because the syntax x(:), uses a function call syntax but would be a special case here. I chose using parenthesis because I wanted this operation to be analogous to the generator syntax in list comprehensions. ListGeneratorsComprehension[ x for x in L ]( x for x in L )SlicingL[a:b:c] L(a:b:c) Tell me what you guys think. Thanks!* ___ 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 416: Add a frozendict builtin type
To close the loop, I've rejected the PEP, adding the following rejection notice: I'm rejecting this PEP. A number of reasons (not exhaustive): * According to Raymond Hettinger, use of frozendict is low. Those that do use it tend to use it as a hint only, such as declaring global or class-level constants: they aren't really immutable, since anyone can still assign to the name. * There are existing idioms for avoiding mutable default values. * The potential of optimizing code using frozendict in PyPy is unsure; a lot of other things would have to change first. The same holds for compile-time lookups in general. * Multiple threads can agree by convention not to mutate a shared dict, there's no great need for enforcement. Multiple processes can't share dicts. * Adding a security sandbox written in Python, even with a limited scope, is frowned upon by many, due to the inherent difficulty with ever proving that the sandbox is actually secure. Because of this we won't be adding one to the stdlib any time soon, so this use case falls outside the scope of a PEP. On the other hand, exposing the existing read-only dict proxy as a built-in type sounds good to me. (It would need to be changed to allow calling the constructor.) -- --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 416: Add a frozendict builtin type
2012/3/22 Guido van Rossum gu...@python.org: To close the loop, I've rejected the PEP, adding the following rejection notice: I'm rejecting this PEP. (...) Hum, you may specify who is I in the PEP. 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] New PEP
On 03/21/2012 07:39 PM, Huan Do wrote: *Hi, I am a graduating Berkeley student that loves python and would like to propose an enhancement to python. My proposal introduces a concept of slicing generator. For instance, if one does x[:] it returns a list which is a copy of x. Sometimes programmers would want to iterate over a slice of x, but they do not like the overhead of constructing another list. Instead we can create a similar operator that returns a generator. My proposed syntax is x(:). The programmers are of course able to set lower, upper, and step size like the following. x(1::-1) This would make code much cleaner in a lot of instances, one example lets say we have a very large list x and we want to sum all the numbers but the last 20, and we only want to loop through the even indices. We would have to do something like this. sum(x[:-20:2]) or we can do a workaround to save space for time and do something like this. sum( value for i, value in enumerate(x) if i -20 and not i % 2 ) But with my proposal we are able do the following. sum(x(:-20:2)) Which affords space without sacrificing expressiveness. For another example lets say we have a problem that we want to check a condition is true for every pairwise element in a list x. def allfriends(x): for i in range(len(x)): for j in range(i+1, len(x)): if not friends(x[i], x[j]): return False return True A more pythonic way is to actually loop through the values instead of the indices like this. def allfriends(x): for i, a in enumerate(x): for j, b in enumerate(x[i+1:]): if not friends(a, b): return False return True This however bring a lot of overhead because we have to construct a new list for every slice call. With my proposal we are able to do this. def allfriends(x): for i, a in enumerate(x): for j, b in enumerate(x(i+1:)): if not friends(a, b): return False return True This proposal however goes against one heuristic in the zen of python, namely “Special cases aren’t special enough to break the rules.” The way that the proposal breaks this rule is because the syntax x(:), uses a function call syntax but would be a special case here. I chose using parenthesis because I wanted this operation to be analogous to the generator syntax in list comprehensions. ListGenerators Comprehension [ x for x in L ]( x for x in L ) Slicing L[a:b:c]L(a:b:c) Tell me what you guys think. Thanks!* ___ 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/animelovin%40gmail.com Hi, I'm not sure i get it.. Assuming your PEP is accepted, what should happens then to the lambda op and standard function calls ? Or Is this merely another case of metaprogramming, which obviously should not be confused with languages such as lisp? Thank you, Etienne ___ 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] New PEP
My proposed syntax is x(:) Change the Python syntax is not a good start. You can already experiment your idea using the slice() type. We would have to do something like this. sum(x[:-20:2]) Do you know the itertools module? It looks like itertools.islice(). 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] New PEP
@Ethan Furman each call to x(:) would return a different iterator, so both sides will have their own information about where they are. Also it is the case that checking for equality of generators does not make the generators to expand out, so checking for equality becomes to checking if they are the same generator object. The following example shows this Python3 (x for x in range(10)) == (x for x in range(10)) False @Etienne lambda is a keyword and would get captured by the lexer, so this should conflict with adding the grammar that would make this work. This is different than function calls because currently arguments of function calls cannot have :, causing `x(:)` to be a syntax error. The grammar that would have to be added would be mutually exclusive from current functionality. @Victor I was not completely familiar with itertools but itertools.islice() seems to have the functionality that I propose. It is great that there already exist a solution that does not change python's syntax. Unless anyone wants to pursue this proposal I will drop it next week. Thanks for your feedback guys On Wed, Mar 21, 2012 at 5:09 PM, Ethan Furman et...@stoneleaf.us wrote: Huan Do wrote: *Hi, I am a graduating Berkeley student that loves python and would like to propose an enhancement to python. My proposal introduces a concept of slicing generator. For instance, if one does x[:] it returns a list which is a copy of x. Sometimes programmers would want to iterate over a slice of x, but they do not like the overhead of constructing another list. Instead we can create a similar operator that returns a generator. My proposed syntax is x(:). The programmers are of course able to set lower, upper, and step size like the following. x(1::-1) The biggest problem with your proposal is that generators don't remember what they have already yielded, so x(:) != x(:) # first time gets everything, second time gets nothing ~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] Python install layout and the PATH on win32
Cleaning up the absurd CC line On Thu, Mar 22, 2012 at 8:03 AM, Paul Moore p.f.mo...@gmail.com wrote: I agree on all points here. I don't understand quite why backward compatibility is being treated so lightly here. But equally, I've made my points and have little further to add. As a non-Windows user who occasionally is the only one available to help Windows users do something (other than install Linux and learn to live freewink/), consistency would be nice. I often have trouble finding the right advice for Windows, even if I feel like looking for it. Dunno if that's a common or important use case, though. ___ 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] New PEP
Huan Do wrote: *Hi, I am a graduating Berkeley student that loves python and would like to propose an enhancement to python. My proposal introduces a concept of slicing generator. For instance, if one does x[:] it returns a list which is a copy of x. Sometimes programmers would want to iterate over a slice of x, but they do not like the overhead of constructing another list. Instead we can create a similar operator that returns a generator. My proposed syntax is x(:). The programmers are of course able to set lower, upper, and step size like the following. x(1::-1) The biggest problem with your proposal is that generators don't remember what they have already yielded, so x(:) != x(:) # first time gets everything, second time gets nothing ~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] New PEP
On Thu, Mar 22, 2012 at 10:28 AM, Huan Do dob...@gmail.com wrote: I was not completely familiar with itertools but itertools.islice() seems to have the functionality that I propose. It is great that there already exist a solution that does not change python's syntax. Unless anyone wants to pursue this proposal I will drop it next week. Just as a further follow-up on the recommended approach for making suggestions: for initial concepts like this one, the python-ideas mailing list is the preferred venue. It's intended for initial validation and refinement of suggestions to see if they're a reasonable topic for the main development list. Many ideas don't make it past the python-ideas stage (either because they have too many problems, they get redirected to a third party PyPI project, or existing alternatives are pointed out, as happened in this case). Regards, 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] PEP 416: Add a frozendict builtin type
On the other hand, exposing the existing read-only dict proxy as a built-in type sounds good to me. (It would need to be changed to allow calling the constructor.) I wrote a small patch to implement this request: http://bugs.python.org/issue14386 I also opened the following issue to support other types than dict for __builtins__: http://bugs.python.org/issue14385 This issue is directly related to pysandbox, but it may help other purpose. 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] GSoC 2012: Python Core Participation?
Good evening, If you are a core committer and volunteer as GSoC mentor for 2012, please let me know by Friday (March 23rd). There is a number of interesting things to implement in packaging, and at least one student who manifested their interest, but unfortunately I am presently unable to say if I’ll have the time to mentor. If other core developers would like to act as mentors like happened last year, I will be available for questions and reviews. Regards ___ 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] [RELEASED] Python 3.3.0 alpha 1
Le 06/03/2012 15:31, Giampaolo Rodolà a écrit : That's why I once proposed to include whatsnew.rst changes every time a new feature is added/committed. Assigning that effort to the release manager or whoever is supposed to take care of this, is both impractical and prone to forgetfulness. Well, it’s the call of the whatsnew author. I think amk wrote the original instructions at the top of each whatsnew file which explain that NEWS is the primary location for logging changes and whatsnew is composed from that file. If Raymond or the new whatsnew author wants to change the rules so that important changes are noted in whatsnew in addition to NEWS, nothing prevents that. 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
