Re: [Python-Dev] regarding HTML mail
On Mon, Mar 19, 2012 at 20:20, Barry Warsaw wrote: >>Can we have some guideline to allow only plain text emails, so as to >>avoid cases like >>http://mail.python.org/pipermail/docs/2012-March/007999.html, where >>you are forced to scroll horizontally in order to read the text. > > docs is a different mailing list than python-dev, but still neither list is > doing any content filtering. We could always enable that if we wanted to get > strict about it. > > In this case, this isn't html email, it's likely this bug: > > https://bugs.launchpad.net/mailman/+bug/558294 Maybe it is, but it's strange that my reply to that mail was nicely done: http://mail.python.org/pipermail/docs/2012-March/008001.html. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
I believe we should make a monotonic_time method that assures monotonicity and be done with it. Forward steadiness can not be guaranteed. No parameters. On Mar 20, 2012 2:56 PM, "Steven D'Aprano" wrote: > On Mon, Mar 19, 2012 at 01:35:49PM +0100, Victor Stinner wrote: > > > Said differently: time.steady(strict=True) is always monotonic (*), > > whereas time.steady() may or may not be monotonic, depending on what > > is avaiable. > > > > time.steady() is a best-effort steady clock. > > > > (*) time.steady(strict=True) relies on the OS monotonic clock. If the > > OS provides a "not really monotonic" clock, Python cannot do better. > > I don't think that is true. Surely Python can guarantee that the clock > will never go backwards by caching the last value. A sketch of an > implementation: > > def monotonic(_last=[None]): >t = system_clock() # best effort, but sometimes goes backwards >if _last[0] is not None: >t = max(t, _last[0]) >_last[0] = t >return t > > Overhead if done in Python may be excessive, in which case do it in C. > > Unless I've missed something, that guarantees monotonicity -- it may not > advance from one call to the next, but it will never go backwards. > > There's probably even a cleverer implementation that will not repeat the > same value more than twice in a row. I leave that as an exercise :) > > As far as I can tell, "steady" is a misnomer. We can't guarantee that > the timer will tick at a steady rate. That will depend on the quality of > the hardware clock. > > > -- > 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/anacrolix%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
On Mar 20, 2012, at 3:33 AM, Matt Joiner wrote: > I believe we should make a monotonic_time method that assures monotonicity > and be done with it. Forward steadiness can not be guaranteed. No parameters. > I think this discussion has veered off a bit into the overly-theoretical. Python cannot really "guarantee" anything here; alternately, it guarantees everything, since if you don't like what Python gives you you can always get your money back :). It's the OS's job to guarantee things. We can all agree that a monotonic clock of some sort is useful. However, maybe my application wants CLOCK_MONOTONIC and maybe it wants CLOCK_MONOTONIC_RAW. Sometimes I want GetTickCount64 and sometimes I want QueryUnbiasedInterruptTime. While these distinctions are probably useless to most applications, they may be of interest to some, and Python really shouldn't make it unduly difficult to get at them. -glyph___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP czar for PEP 3144?
Guido van Rossum wrote: I personally like having 'iter' in the name (e.g. iterkeys() -- note that we dropped this in Py3k because it's no longer an iterator, it's a dict view now. But I don't want to promote that style for ipaddr.py. +1 from me too on having all methods that return iterators clearly indicating so. It's an important distinction, and it can be very confusing if some methods of an API return iterators and others don't with no easy way of remembering which is which. -- 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] Issue #10278 -- why not just an attribute?
2012/3/20 Jim J. Jewett : > > > In http://mail.python.org/pipermail/python-dev/2012-March/117762.html > Georg Brandl posted: > >>> + If available, a monotonic clock is used. By default, if *strict* is >>> False, >>> + the function falls back to another clock if the monotonic clock failed >>> or is >>> + not available. If *strict* is True, raise an :exc:`OSError` on error or >>> + :exc:`NotImplementedError` if no monotonic clock is available. > >> This is not clear to me. Why wouldn't it raise OSError on error even with >> strict=False? Please clarify which exception is raised in which case. > > Passing strict as an argument seems like overkill since it will always > be meaningless on some (most?) platforms. Why not just use a function > attribute? Those few users who do care can check the value of > time.steady.monotonic before calling time.steady(); exceptions raised > will always be whatever the clock actually raises. The clock is chosen at runtime. You might use a different clock at each call. In most cases, Python should chose a clock at the first call and reuse it for next calls. For example, on Linux the following clocks are tested: - clock_gettime(CLOCK_MONONOTIC_RAW) - clock_gettime(CLOCK_MONONOTIC) - gettimeofday() - ftime() 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] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
> I think this discussion has veered off a bit into the overly-theoretical. > Python cannot really "guarantee" anything here That's why the function name was changed from time.monotonic() to time.steady(strict=True). If you want to change something, you should change the documentation to list OS limitations. > It's the OS's job to guarantee things Correct, most Python modules exposing OS functions are thin wrappers and don't add any magic. When we need a higher level API, we write a new module: like shutil enhancing the os module. 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 install layout and the PATH on win32
For those who missed it, in http://bugs.python.org/issue14302, Martin recently commented: """ After more discussion, it appears that this change is too incompatible to be done in a single release. Therefore, I propose a long-term change into this direction, with the actual change not happening until 3.5. """ While I'm still unclear on the actual benefits of this, Martin's approach strikes a reasonable compromise so I withdraw my objections. Thanks, 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] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
On Tue, 20 Mar 2012 04:43:44 -0400, Glyph wrote: > > On Mar 20, 2012, at 3:33 AM, Matt Joiner wrote: > > > I believe we should make a monotonic_time method that assures monotonicity > > and be done with it. Forward steadiness can not be guaranteed. No > > parameters. > > > > I think this discussion has veered off a bit into the overly-theoretical. > Python cannot really "guarantee" anything here; alternately, it guarantees > everything, since if you don't like what Python gives you you can always get > your money back :). It's the OS's job to guarantee things. We can all agree > that a monotonic clock of some sort is useful. > > However, maybe my application wants CLOCK_MONOTONIC and maybe it wants > CLOCK_MONOTONIC_RAW. Sometimes I want GetTickCount64 and sometimes I want > QueryUnbiasedInterruptTime. While these distinctions are probably useless to > most applications, they may be of interest to some, and Python really > shouldn't make it unduly difficult to get at them. Something like: time.steady(require_clock=None) where require_clock can be any of BEST, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, GetTickCount64, QueryUnbiastedInterruptTime, etc? Then None would mean it is allowable to use time.time and the cache-the-last-time-returned algorithm, and BEST would be Victor's current 'strict=True'. And if you require a Linux clock on Windows or vice-versa, on your own head be it :) --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
[Python-Dev] pysandbox 1.5 released
pysandbox is a Python sandbox. By default, untrusted code executed in the sandbox cannot modify the environment (write a file, use print or import a module). But you can configure the sandbox to choose exactly which features are allowed or not, e.g. import sys module and read /etc/issue file. http://pypi.python.org/pypi/pysandbox https://github.com/haypo/pysandbox/ Main changes since pysandbox 1.0.3: - More modules and functions are allowed: math, random and time modules, and the compile() builtin function for example - Drop the timeout feature: it was not effective on CPU intensive functions implemented in C - (Read the ChangeLog to see all changes.) pysandbox has known limitations: - it is unable to limit memory or CPU - it does not protect against bugs (e.g. crash) or vulnerabilities in CPython - dict methods able to modify a dict (e.g. dict.update) are disabled to protect the sandbox namespace, but dict[key]=value is still accepted It is recommanded to run untrusted code in a subprocess to workaround these limitations. pysandbox doesn't provide an helper yet. pysandbox is used by an IRC bot (fschfsch) to evaluate a Python expression. The bot uses fork() and setrlimit() to limit memory and to implement a timeout. https://github.com/haypo/pysandbox/wiki/fschfsch -- The limitation on dict methods is required to deny the modification of the __builtins__ dictionary. I proposed the PEP 416 (frozendict) but Guido van Rossum is going to reject it. I don't see how to fix this limitation without modifying CPython. http://www.python.org/dev/peps/pep-0416/ Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP czar for PEP 3144?
Greg Ewing wrote: Guido van Rossum wrote: I personally like having 'iter' in the name (e.g. iterkeys() -- note that we dropped this in Py3k because it's no longer an iterator, it's a dict view now. But I don't want to promote that style for ipaddr.py. +1 from me too on having all methods that return iterators clearly indicating so. It's an important distinction, and it can be very confusing if some methods of an API return iterators and others don't with no easy way of remembering which is which. With the prevalence of iterators in Python 3 [1], the easy way is to have the API default to iterators, drop 'iter' from the names, and use 'list' in the names to signal the oddball cases where a list is returned instead. ~Ethan~ [1] http://mail.python.org/pipermail/python-dev/2012-March/117815.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32
On 3/20/2012 5:48 AM, Mark Hammond wrote: > While I'm still unclear on the actual benefits of this, Martin's > approach strikes a reasonable compromise so I withdraw my objections. Ok. I was out of town and so could not respond to most of the latest discussion. A question for you Mark, Paul, (and anyone else): Éric correctly points out that there are actually two distinct changes proposed here: 1. Moving the Python binary 2. Changing from "Scripts" to "bin" So far, the primary resistance seems to be to item #1 - moving the python binary. There have been a few people who have noted that #2 will require some code to change (i.e. Paul), but I don't see lots of resistance. Am I reading you correctly? Thanks, VanCIRCULAR 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
On 20/03/2012 14:08, VanL wrote: On 3/20/2012 5:48 AM, Mark Hammond wrote: While I'm still unclear on the actual benefits of this, Martin's approach strikes a reasonable compromise so I withdraw my objections. Ok. I was out of town and so could not respond to most of the latest discussion. A question for you Mark, Paul, (and anyone else): Éric correctly points out that there are actually two distinct changes proposed here: 1. Moving the Python binary 2. Changing from "Scripts" to "bin" So far, the primary resistance seems to be to item #1 - moving the python binary. There have been a few people who have noted that #2 will require some code to change (i.e. Paul), but I don't see lots of resistance. Speaking for myself, I think that's true. At present I tend to add /scripts to my path and I can just as easily add /bin (for whatever version I'm running most often on that machine). 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] Python install layout and the PATH on win32
Germane to this discussion, I reached out for feedback. Most people didn't care about the issue, or were slightly inclined to have it be uniform across platforms. As Terry mentioned, I think that long-term uniformity will benefit everybody down the line, and that is the way to go. The most interesting feedback, though, related to moving the Python exe and placing it on the PATH. I got one argument back that I thought was persuasive here: We want things to 'just work.' Specifically, the following sequence of events should not require any fiddling on Windows: 1. Install python. 2. Open up a shell and run "python" 3. Use pip or easy_install to install regetron (a package that installs an executable file). 4. Run regetron. For step #2, the python exe needs to be on the PATH. For steps 3 and 4, the binaries directory needs to be on the PATH. In hearing from a couple people who teach python to beginners, this is a substantial hurdle - the first thing they need to do is to edit their environment to add these directories to the PATH. This is orthogonal to the Scripts/bin issue, but I thought it should be brought up. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32
> In hearing from a couple people who teach python to beginners, this is a > substantial hurdle - the first thing they need to do is to edit their > environment to add these directories to the PATH. This is something I never understood. On Windows, it's custom to launch programs from the start menu, and Python is easy enough to find on the start menu (e.g. by typing "Python"). Why do people want to launch it by opening a shell window, then typing python? In any case, I have given up my resistance to the feature request for automatic path fiddling several years ago, and was since waiting for a contribution of a patch that makes it happen. 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] pysandbox 1.5 released
Well, I really hope that the PEP regarding frozendict will be accepted. Especially due to the fact that the required changes are small. With the recent projects like clojure-py, blog posts like http://goo.gl/bFB5x (Python becomes a platform), your pysandbox, it became clear that people start evaluating Python on a different level. And for developing custom languages, deeply experimenting with coroutines and who knows what else, frozendict is a missing concept in python's immutable types structure. On 2012-03-20, at 8:32 AM, Victor Stinner wrote: > pysandbox is a Python sandbox. By default, untrusted code executed in > the sandbox cannot modify the environment (write a file, use print or > import a module). But you can configure the sandbox to choose exactly > which features are allowed or not, e.g. import sys module and read > /etc/issue file. > > http://pypi.python.org/pypi/pysandbox > https://github.com/haypo/pysandbox/ > > Main changes since pysandbox 1.0.3: > > - More modules and functions are allowed: math, random and time > modules, and the compile() builtin function for example > - Drop the timeout feature: it was not effective on CPU intensive > functions implemented in C > - (Read the ChangeLog to see all changes.) > > pysandbox has known limitations: > > - it is unable to limit memory or CPU > - it does not protect against bugs (e.g. crash) or vulnerabilities in CPython > - dict methods able to modify a dict (e.g. dict.update) are disabled > to protect the sandbox namespace, but dict[key]=value is still > accepted > > It is recommanded to run untrusted code in a subprocess to workaround > these limitations. pysandbox doesn't provide an helper yet. > > pysandbox is used by an IRC bot (fschfsch) to evaluate a Python > expression. The bot uses fork() and setrlimit() to limit memory and to > implement a timeout. > > https://github.com/haypo/pysandbox/wiki/fschfsch > > -- > > The limitation on dict methods is required to deny the modification of > the __builtins__ dictionary. I proposed the PEP 416 (frozendict) but > Guido van Rossum is going to reject it. I don't see how to fix this > limitation without modifying CPython. > > http://www.python.org/dev/peps/pep-0416/ > > 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/yselivanov.ml%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32
On 3/20/2012 10:52 AM, "Martin v. Löwis" wrote: In hearing from a couple people who teach python to beginners, this is a substantial hurdle - the first thing they need to do is to edit their environment to add these directories to the PATH. This is something I never understood. On Windows, it's custom to launch programs from the start menu, and Python is easy enough to find on the start menu (e.g. by typing "Python"). Why do people want to launch it by opening a shell window, then typing python? Because the workflow you suggest is broken when you are developing with Python. Assume that you are iteratively building up a program in Python. You aren't sure if it is right yet, so you want to get it into python to test it and see the output. There are three ways to do this. 1. Run python from the start menu. - Import sys, fiddle with sys.path to add my module, import/run my module, do my tests. When you exit /hard error out, the python window disappears. 2. Double-click the .py file - Runs the file, but then disappears immediately (unless you put in something like input/raw_input just to keep the window open) - and if it errors out, you never see the traceback - it disappears too fast. 3. Get a shell and run python. This requires cd'ing to the directory where my .py file is, but then I run/import it and I see the information. To repeat the process, either type python again or just press arrow-up. 4. (Not relevant here) - do it in an IDE that does #3 for you. #3 is the only reasonable way to do development if you are not in an IDE. Thanks, Van ___ 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 Tue, Mar 20, 2012 at 10:52, "Martin v. Löwis" wrote: >> In hearing from a couple people who teach python to beginners, this is a >> substantial hurdle - the first thing they need to do is to edit their >> environment to add these directories to the PATH. > > This is something I never understood. On Windows, it's custom to launch > programs from the start menu, and Python is easy enough to find on the > start menu (e.g. by typing "Python"). Why do people want to launch it by > opening a shell window, then typing python? I've never thought about doing it otherwise. If I want to run the C:\Users\brian\example\sample.py script, I'd open a CMD and move to the example directory and execute the sample script. The class of about 60 people I taught a few years back at a previous employer all did the same thing without me specifying. Everyone was used to working in the command line for other tasks, from using other languages to running our products, so it was natural to them to run it that way. > In any case, I have given up my resistance to the feature request for > automatic path fiddling several years ago, and was since waiting for > a contribution of a patch that makes it happen. I'm working on the changes we discussed at PyCon. http://bugs.python.org/issue3561 has an version of the patch doing it the old way - I hope to have the new way figured out soon. ___ 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
> 1. Run python from the start menu. > - Import sys, fiddle with sys.path to add my module, import/run my > module, do my tests. When you exit /hard error out, the python window > disappears. > > 2. Double-click the .py file > - Runs the file, but then disappears immediately (unless you put in > something like input/raw_input just to keep the window open) - and if it > errors out, you never see the traceback - it disappears too fast. > > 3. Get a shell and run python. > This requires cd'ing to the directory where my .py file is, but then I > run/import it and I see the information. To repeat the process, either > type python again or just press arrow-up. > > 4. (Not relevant here) - do it in an IDE that does #3 for you. > > #3 is the only reasonable way to do development if you are not in an IDE. No - there is an version #3a: 3.a) Get a shell and run the script CD into the directory, then directly run foo.py, without prefixing it with python.exe. This doesn't require any changes to the path, and is shorter in usage than having the path specified. With PEP 397, you will be able to run "py foo.py" without path modification, and it will get the correct Python version even (which neither the path manipulation nor the file association could achieve). 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] Python install layout and the PATH on win32
On 3/20/2012 11:19 AM, "Martin v. Löwis" wrote: No - there is an version #3a: 3.a) Get a shell and run the script CD into the directory, then directly run foo.py, without prefixing it with python.exe. This doesn't require any changes to the path, and is shorter in usage than having the path specified. Fair enough - but notice: 1) You are still in the shell, instead of running from the start menu; and 2) what if you want to import it and test a function with various inputs? You either implement a request/response in a __main__ block, or type "python" and then import foo. ___ 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 3/20/2012 12:02 PM, VanL wrote: On 3/20/2012 10:52 AM, "Martin v. Löwis" wrote: In hearing from a couple people who teach python to beginners, this is a substantial hurdle - the first thing they need to do is to edit their environment to add these directories to the PATH. This is something I never understood. On Windows, it's custom to launch programs from the start menu, and Python is easy enough to find on the start menu (e.g. by typing "Python"). Why do people want to launch it by opening a shell window, then typing python? Perhaps as the number of *nix users increases, the number of (*nix & windows) developer/users increases. 3. Get a shell and run python. This requires cd'ing to the directory where my .py file is, but then I run/import it and I see the information. When IDLE crashes, running it from a cmd window is the only way to get a traceback to help diagnose the problem. -- 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] Python install layout and the PATH on win32
On 3/20/2012 11:19 AM, "Martin v. Löwis" wrote: No - there is an version #3a: 3.a) Get a shell and run the script CD into the directory, then directly run foo.py, without prefixing it with python.exe. This doesn't require any changes to the path, and is shorter in usage than having the path specified. With PEP 397, you will be able to run "py foo.py" without path modification, and it will get the correct Python version even (which neither the path manipulation nor the file association could achieve). There is also one more scenario, assuming that your project includes other libraries. You can run setup.py directly in your example, but what about pip or easy_install? Both of those require the binaries directory to also be on the PATH - requiring at least a little PATH manipulation. Thanks, Van ___ 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 20 March 2012 14:08, Lindberg, Van wrote: > On 3/20/2012 5:48 AM, Mark Hammond wrote: >> While I'm still unclear on the actual benefits of this, Martin's >> approach strikes a reasonable compromise so I withdraw my objections. > > > Ok. I was out of town and so could not respond to most of the latest > discussion. > > A question for you Mark, Paul, (and anyone else): Éric correctly points > out that there are actually two distinct changes proposed here: > > 1. Moving the Python binary > 2. Changing from "Scripts" to "bin" > > So far, the primary resistance seems to be to item #1 - moving the > python binary. There have been a few people who have noted that #2 will > require some code to change (i.e. Paul), but I don't see lots of resistance. > > Am I reading you correctly? Somewhat. I don't really object to #1, but mildly object to #2. I also note that the proposals round the Lib directory seem to have disappeared. I assume those have been dropped - they were the ones I did object to. I also note that I'm assuming virtualenv will change to match whatever the Python version it's referencing does. I don't see how you can guarantee that, but if there are discrepancies between virtualenvs and installed Pythons, my level of objection goes up a little more. Martin's suggestion of an intermediate registry entry to ease transition doesn't help me. So I don't care about that. See a later message for my comments on PATH as it affects this discussion, though. 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] Python install layout and the PATH on win32
When IDLE crashes, running it from a cmd window is the only way to get a traceback to help diagnose the problem. Certainly. In this case, there is no PATH issue, though: you have to CD into the Python installation, anyway, to start IDLE - and there you have python.exe in the current directory. Plus, you can still launch Lib\idlelib\idle.py without prefixing it with python.exe. 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] Python install layout and the PATH on win32
On 03/20/2012 12:19 PM, Paul Moore wrote: > I also note that I'm assuming virtualenv will change to match whatever > the Python version it's referencing does. I don't see how you can > guarantee that, but if there are discrepancies between virtualenvs and > installed Pythons, my level of objection goes up a little more. Virtualenv will follow whatever Python does, yes. Carl signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32
On 13 March 2012 20:43, VanL wrote:
> Following up on conversations at PyCon, I want to bring up one of my
> personal hobby horses for change in 3.3: Fix install layout on Windows, with
> a side order of making the PATH work better.
As this is being considered an 'incompatible change' on the bug
tracker item [1] in any case, I'd like to mention that this might also
be a convenient moment to re-think the default install location. After
all, software is supposed to be installed in %programfiles% on
windows, not in c:\.
I asked a question about this on IRC, to which the response was that
there were two main reasons to install python in c:\pythonxy:
1 - issues due to spaces ('Program Files') or non-ascii characters in
the path ('Fișiere Program' on a Romanian windows). These issues are
supposed to be fixed by now (?).
2 - issues due to permissions - installing python / packages in
%programfiles% may require administrator rights.
Historical note: in python 1.5 the install location was changed to
\program files\.., but in python 1.6/2.0 it was changed (back?) to
\pythonxy. [2 @ 10618, 10850, 13804]
[1] http://bugs.python.org/issue14302
[2] http://hg.python.org/cpython/file/a5add01e96be/Misc/HISTORY
___
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 20 March 2012 14:27, VanL wrote: > Germane to this discussion, I reached out for feedback. Most people didn't > care about the issue, or were slightly inclined to have it be uniform across > platforms. > > As Terry mentioned, I think that long-term uniformity will benefit everybody > down the line, and that is the way to go. > > The most interesting feedback, though, related to moving the Python exe and > placing it on the PATH. I got one argument back that I thought was > persuasive here: We want things to 'just work.' Specifically, the following > sequence of events should not require any fiddling on Windows: > > 1. Install python. > 2. Open up a shell and run "python" > 3. Use pip or easy_install to install regetron (a package that installs an > executable file). > 4. Run regetron. > > For step #2, the python exe needs to be on the PATH. For steps 3 and 4, the > binaries directory needs to be on the PATH. This is covered (better, IMO) by PEP 397 - Python Launcher for Windows. Step 2, just run "py". If you prefer a particular version, run "py -2" or "py -3" or "py -3.2". Adding python.exe to PATH actually makes this message *worse* as it confuses the issue. In a post-PEP 397 world, I would say that we should be telling Windows users *not* to run python.exe at all. (Unless they are using virtualenvs - maybe PEP 397 could do with an extra option to run the Python from the currently active virtualenv, but that's a side issue). If we do put python.exe on PATH (whether it's in bin or not), we have to debate how to handle people having multiple versions of python on their machine. In a post-PEP 397 world, no Python is "the machine default" - .py files are associated with py.exe, not python.exe, so we have to consider the following 3 commands being run from a shell prompt: 1. myprog.py 2. py myprog.py 3. python myprog.py 1 and 2 will always do the same thing. However, 3 could easily do something completely different, if the Python in the #! line differs from the one found on PATH. To me, this implies that it's better for (3) to need explicit user action (setting PATH) if it's to do anything other than give an error. But maybe that's just me. I've been hit too often by confusion caused by *not* remembering this fact. Note: I am using Vinay's py.exe all the time these days, so my comments about a "post-PEP 397 world" are from my direct experience. For your steps 3 and 4, there is certainly user intervention required as things stand. It would indeed be nice if "regetron" just worked as expected. But I'd argue a few points here: 1. On Windows, if regetron was not explicitly an application for working with my Python installation (like pip, easy_install, nose, etc) then I'd prefer it to be packaged as a standalone application using cx_Freeze or py2exe. I've had too many "applications" break because I accidentally uninstalled a dependency from my Python installation to want anything that is an end-user application installed into my Python scripts/bin directory. 2. If regetron is not an end-user application, it should really be getting installed in, and run from, a virtualenv. And in that case, activating the right virtualenv is part of the workflow. And that sets up PATH as needed, so there's no problem here. The problem with your example is that it depends on the package/executable. I looked at regetron (I thought it was a made up example at first!) and it seems clear to me that it should either be packaged up with py2exe/cx_Freeze, or (if it's sufficiently version-independent) sit outside of Python's installation tree. I can't see any reason why I'd expect a "regetron" command to work or not depending on which copy of Python on my PC I have active. But other applications may differ, I guess. I concede that the picture is much simpler when people only ever have a single version of Python on their machine. So for that case alone, maybe the "Make this Python the default" option in the installer should add the bin directory (or Scripts and the root, under the current layout) to the PATH. But equally, if the installer detects another copy of Python already installed, it should probably warn the user loudly that it's important to understand the implications of setting "make this Python the default", and should not set it by default (this may be the current behaviour, I don't know). I have no idea what proportion of Python users on Windows have multiple versions installed. I also have no idea how many such users work on the command line. My guess would be "not that many" and "not that many of the first group" respectively... But there are big groups like scientists and web developers who could sway these figures a lot. > In hearing from a couple people who teach python to beginners, this is a > substantial hurdle - the first thing they need to do is to edit their > environment to add these directories to the PATH. I'd be curious as to how much PEP 397's py.exe would have helped those people.
Re: [Python-Dev] Python install layout and the PATH on win32
On 3/20/2012 1:50 PM, Merlijn van Deen wrote: On 13 March 2012 20:43, VanL wrote: Following up on conversations at PyCon, I want to bring up one of my personal hobby horses for change in 3.3: Fix install layout on Windows, with a side order of making the PATH work better. As this is being considered an 'incompatible change' on the bug tracker item [1] in any case, I'd like to mention that this might also be a convenient moment to re-think the default install location. After all, software is supposed to be installed in %programfiles% on windows, not in c:\. I don't particularly care about this issue, as I always install to my own location (c:\lib\python\X.Y), but I don't think that the default location of the install should be confounded with this issue - or should I say these issues, because we already have two. ___ 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 3/20/2012 1:56 PM, Paul Moore wrote: This is covered (better, IMO) by PEP 397 - Python Launcher for Windows. Step 2, just run "py". If you prefer a particular version, run "py -2" or "py -3" or "py -3.2". Interesting. I haven't played around with that at all, so can't comment. I will have to try it out. Adding python.exe to PATH actually makes this message *worse* as it confuses the issue. In a post-PEP 397 world, I would say that we should be telling Windows users *not* to run python.exe at all. (Unless they are using virtualenvs - maybe PEP 397 could do with an extra option to run the Python from the currently active virtualenv, but that's a side issue). I think that having the PATH manipulation be optional might address this issue. I also think that the PEP 397 launcher should respect virtualenvs - at least the built-in pyvenvs - or else there will be lots of confusion. For your steps 3 and 4, there is certainly user intervention required as things stand. It would indeed be nice if "regetron" just worked as expected. But I'd argue a few points here: 1. On Windows, if regetron was not explicitly an application for working with my Python installation (like pip, easy_install, nose, etc) then I'd prefer it to be packaged as a standalone application using cx_Freeze or py2exe. I've had too many "applications" break because I accidentally uninstalled a dependency from my Python installation to want anything that is an end-user application installed into my Python scripts/bin directory. Maybe so - and I would probably agree that for any packaged application, bundling it into its own environment (or at least its own virtualenv) is the best practice. But what about pip, easy_install, nose, cython, pygments, PIL, etc, that do this and are meant to be associated with a particular python version? Substitute "nose" for "regetron" if you want, and there is still a problem. The problem with your example is that it depends on the package/executable. I looked at regetron (I thought it was a made up example at first!) ...! I got the name from the feedback I received. I thought it was made up too. I have no idea what proportion of Python users on Windows have multiple versions installed. I also have no idea how many such users work on the command line. My guess would be "not that many" and "not that many of the first group" respectively... But there are big groups like scientists and web developers who could sway these figures a lot. There are a number of casual users that probably only have one version installed, but every python user/dev on windows that I know has one python that they consider to be "python," and everything else needs to be launched with a suffix (e.g., python26.exe). This is usually put earlier on the PATH so that it gets picked up first. For example, right now I have 2.6, 2.7, 3.2, jython, and pypy all installed, and I have "python" pointing to 2.7. I'd be curious as to how much PEP 397's py.exe would have helped those people. But yes, it's an issue. Although someone at some point will have to introduce those beginners to the question of Python 2 vs Python 3, and PATH pain will hit them then, anyway. I would imagine that it would help steps 1 and 2, but 3 and 4 would be problematic (how can you pip install something using py?) unless you were in a virtualenv, and then (unless py respected the virtualenv) the whole thing would be problematic, because there wouldn't be one clear way to do it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32
On 3/20/2012 1:19 PM, Paul Moore wrote:
> Somewhat. I don't really object to #1, but mildly object to #2. I also
> note that the proposals round the Lib directory seem to have
> disappeared. I assume those have been dropped - they were the ones I
> did object to.
They are of secondary importance to me, and I would be mostly ok to drop
them - but I would like to understand your objection.
I would like to know if you would object to user lib installs matching
the system install. I.e., would it cause problems with you if it were
just 'lib' everywhere, with no 'lib/python{version}'? It sounded like
adding the version directory was the issue.
Thanks,
VanCIRCULAR 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-checkins] cpython: Issue #14328: Add keyword-only parameters to PyArg_ParseTupleAndKeywords.
2012/3/20 larry.hastings : > http://hg.python.org/cpython/rev/052779d34945 > changeset: 75842:052779d34945 > parent: 75839:1c0058991740 > user: Larry Hastings > date: Tue Mar 20 20:06:16 2012 + > summary: > Issue #14328: Add keyword-only parameters to PyArg_ParseTupleAndKeywords. > > They're optional-only for now (unlike in pure Python) but that's all > I needed. The syntax can easily be relaxed if we want to support > required keyword-only arguments for extension types in the future. > > files: > Doc/c-api/arg.rst | 9 +++ > Lib/test/test_getargs2.py | 74 ++- > Modules/_testcapimodule.c | 20 ++- > Python/getargs.c | 34 - > 4 files changed, 134 insertions(+), 3 deletions(-) Forgot about Misc/NEWS? -- Regards, Benjamin ___ 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 20 March 2012 19:35, Lindberg, Van wrote:
> I would like to know if you would object to user lib installs matching
> the system install. I.e., would it cause problems with you if it were
> just 'lib' everywhere, with no 'lib/python{version}'? It sounded like
> adding the version directory was the issue.
User lib installs don't bother me as I don't use them. But yes, it's
the version directory that bothers me.
So if you're proposing simply making the user lib install match the
system install, both being lust "lib", then that's fine. I was
somewhat confused about what you were proposing, that's all.
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] Python install layout and the PATH on win32
On 20 March 2012 19:22, VanL wrote: > There are a number of casual users that probably only have one version > installed, but every python user/dev on windows that I know has one python > that they consider to be "python," and everything else needs to be launched > with a suffix (e.g., python26.exe). This is usually put earlier on the PATH > so that it gets picked up first. For example, right now I have 2.6, 2.7, > 3.2, jython, and pypy all installed, and I have "python" pointing to 2.7. But no Python I am aware of *has* a suffixed version (python26.exe). Renaming/copying is (in my view) a far more invasive change than simply modifying PATH (and it doesn't help the whole nose/regetron situation either). Serious question: Given a brand new PC, if you were installing Python 2.7, 3.2, 3.3a1, jython, and pypy, what would you do (beyond simply running 5 installers) to get your environment set up the way you want? For me, I'd 1. Install the Python launcher (only until 3.3 includes it) 2. Edit py.ini to tailor py.exe to my preferred defaults for Python and Python3. 3. Install my powershell module which allows me to switch which Python is on PATH Done. (That doesn't cater for pypy or jython, as I don't use them. But I'd probably use a couple of aliases for the rare uses I'd make of them) >> I'd be curious as to how much PEP 397's py.exe would have helped >> those people. But yes, it's an issue. Although someone at some point >> will have to introduce those beginners to the question of Python 2 vs >> Python 3, and PATH pain will hit them then, anyway. > > I would imagine that it would help steps 1 and 2, but 3 and 4 would be > problematic (how can you pip install something using py?) unless you were in > a virtualenv, and then (unless py respected the virtualenv) the whole thing > would be problematic, because there wouldn't be one clear way to do it. There isn't one clear way right now. And adding one particular version to PATH only helps if you only *have* one version. My current preference is as follows: 1. If you only ever have one Python on your machine, add it (and its scripts dir) to PATH and be done with it. Unfortunately, we're in the throes of the Python 2-3 transition, and not many people can manage with the one-Python restriction (I certainly can't). Also the Python installer can't detect if that's what you want. 2. Otherwise, use virtualenvs for anything that isn't being packaged up as a standalone environment. Activate as needed. 3. To access your system python(s) use py.exe with a version flag if needed. Never (or nearly never) install packages in the system Python. 4. To run scripts, use #! lines and the py.exe association (and set PATHEXT if you want) to associate the precise Python you want with the script. I have to say, I've recently discovered virtualenv, so the above is the opinion of a newly-converted zealot - so take with a pinch of salt :-) 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] Python install layout and the PATH on win32
On 3/20/2012 3:15 PM, Paul Moore wrote:
On 20 March 2012 19:35, Lindberg, Van wrote:
I would like to know if you would object to user lib installs matching
the system install. I.e., would it cause problems with you if it were
just 'lib' everywhere, with no 'lib/python{version}'? It sounded like
adding the version directory was the issue.
User lib installs don't bother me as I don't use them. But yes, it's
the version directory that bothers me.
So if you're proposing simply making the user lib install match the
system install, both being lust "lib", then that's fine. I was
somewhat confused about what you were proposing, that's all.
I was originally going to make it match posix-user installs, but just
plain posix (no version directory) is just fine with me too.
___
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 3/20/2012 11:50 AM, Merlijn van Deen wrote:
As this is being considered an 'incompatible change' on the bug
tracker item [1] in any case, I'd like to mention that this might also
be a convenient moment to re-think the default install location. After
all, software is supposed to be installed in %programfiles% on
windows, not in c:\.
I asked a question about this on IRC, to which the response was that
there were two main reasons to install python in c:\pythonxy:
1 - issues due to spaces ('Program Files') or non-ascii characters in
the path ('Fișiere Program' on a Romanian windows). These issues are
supposed to be fixed by now (?).
2 - issues due to permissions - installing python / packages in
%programfiles% may require administrator rights.
I also wondered about %programfiles%, and had heard of issue #1, and
would hope that it is not a real issue in modern times, but haven't
attempted to test to determine otherwise.
However, the in the first quoted paragraph there is an incorrect
statement... the last sentence is simply not true. While software that
is installed "for everyone" on the computer is supposed to be installed
in %programfiles%, software that is installed for "user only" need not
be, and in fact, it is recommended (at least by installer software I've
used) that the alternate path is (XP) C:\Documents and
Settings\\Local Settings\Application Data or (7)
C:\Users\\AppData\Local (I think, I haven't found certain
documentation about this).
Or is it even possible to install something for "user only" anymore? I
haven't been involved with installers lately (have been doing portable
apps, no install needed). Certainly the "program files (x86)" business
adds an extra wrinkle to it, somehow, on 64 bit machines, and I'm not
hitting the right sites on my Google searches to discover anything about
that, so that's why I'm wondering if it has been deprecated.
Speaking of which, it would be nice to have "Portable Python" be part of
the standard reportoire of packages available.
___
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 3/20/2012 3:31 PM, Paul Moore wrote: > Serious question: Given a brand new PC, if you were installing Python > 2.7, 3.2, 3.3a1, jython, and pypy, what would you do (beyond simply > running 5 installers) to get your environment set up the way you want? I install each python in its own directory: C:/lib/python/2.7 C:/lib/python/3.2 C:/lib/python/3.3 C:/lib/jython C:/lib/pypy Jython and Pypy get their own directories because they can have different version compatibilities. I then edit my distutils.command.install and patch pip/virtualenv so that all my directories are 'bin'/'lib'/'include'. I have never used the py.exe runner, but I then choose whichever Python is my default (right now 2.7, but hoping that I will be able to switch during the 3.3 timeframe) and that gets put on the PATH, along with its 'bin' directory. The other root dirs/bin directories get put on the PATH after the default Python. I don't remember whether I did it or whether it is installed that way, but I have a python2.6.exe and an pythonw.2.6.exe, etc, and all the individual installers include both a pip and a pip-2.6 version (or whatever that install has). I honestly don't remember - I would love to have someone else check. With this setup, I get my default choice anytime I type "python" and a specific interpreter version when I specify it. Same with installers, etc. I then install virtualenv and virtualenvwrapper-powershell and do all of my development out of virtualenvs. Occasionally I will install something to the system python if it is a pain to compile and I am installing a binary version from somewhere, but I generally try to keep the system python(s) clean.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
On 21/03/2012 1:08 AM, Lindberg, Van wrote: On 3/20/2012 5:48 AM, Mark Hammond wrote: While I'm still unclear on the actual benefits of this, Martin's approach strikes a reasonable compromise so I withdraw my objections. Ok. I was out of town and so could not respond to most of the latest discussion. A question for you Mark, Paul, (and anyone else): Éric correctly points out that there are actually two distinct changes proposed here: 1. Moving the Python binary 2. Changing from "Scripts" to "bin" So far, the primary resistance seems to be to item #1 - moving the python binary. There have been a few people who have noted that #2 will require some code to change (i.e. Paul), but I don't see lots of resistance. Am I reading you correctly? Well - as Paul implies, there are 2 distinct changes being proposed, but in 2 different environments. For an installed Python: If it has to move, it may as well move to somewhere consistent with other platforms. IOW, moving to "bin" seems preferable to moving to Scripts. My initial objection was to moving it at all in an installed Python. For a virtual env, we are talking about moving it *from* Scripts to bin, which may cause some people different problems. However, that isn't the concern I was expressing and I'd hate to see virtual envs remain inconsistent with an installed Python after this effort. So I'm assuming that: * The executable (and DLL) are moved to a "bin" directory in an installed Python. * distutils etc will change to install all "scripts" (or executables generated from scripts) into that same directory. IOW, "Scripts" would die. * A virtual-env would have an almost identical layout to an installed Python. Cheers, 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] Python install layout and the PATH on win32
On 3/20/2012 4:49 PM, Mark Hammond wrote: So I'm assuming that: * The executable (and DLL) are moved to a "bin" directory in an installed Python. * distutils etc will change to install all "scripts" (or executables generated from scripts) into that same directory. IOW, "Scripts" would die. * A virtual-env would have an almost identical layout to an installed Python. Yes. I would make your point #3 stronger - I would like a virtualenv to have an identical layout to an installed python, at least with reference to the names of directories and the location of binaries. The base directory would be the only difference. Thanks, Van ___ 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 20 March 2012 22:00, VanL wrote: > On 3/20/2012 4:49 PM, Mark Hammond wrote: >> >> So I'm assuming that: >> * The executable (and DLL) are moved to a "bin" directory in an installed >> Python. >> * distutils etc will change to install all "scripts" (or executables >> generated from scripts) into that same directory. IOW, "Scripts" would die. 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. 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] Python install layout and the PATH on win32
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
On 13 March 2012 20:43, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows, with
a side order of making the PATH work better.
As this is being considered an 'incompatible change' on the bug
tracker item [1] in any case, I'd like to mention that this might also
be a convenient moment to re-think the default install location. After
all, software is supposed to be installed in %programfiles% on
windows, not in c:\.
I asked a question about this on IRC, to which the response was that
there were two main reasons to install python in c:\pythonxy:
1 - issues due to spaces ('Program Files') or non-ascii characters in
the path ('Fișiere Program' on a Romanian windows). These issues are
supposed to be fixed by now (?).
2 - issues due to permissions - installing python / packages in
%programfiles% may require administrator rights.
Apart from personal preference (ie, I prefer the status quo here), the
second issue is a bit of a killer. Even an administrator can not write
to Program Files unless they are using an "elevated" process (ie,
explicitly use "Run as Administrator" and confirm the prompt.
This means that any installer wanting to write .py files into the Python
install must be elevated, and any Python process wanting to generate
.pyc files must also be elevated. So even if an installer does arrange
elevation, unless that installer also compiles all .pyc and .pyo files
at install time, Python would fail to generate the .pyc files on first
use. While Python will probably fail silently and still continue to
work, it will have a significant performance impact.
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
[Python-Dev] Playing with a new theme for the docs
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/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
Nice and clean, but looks too similar to newer Google properties... Also I see that (like Google) you're falling for the fallacy of using less contrast. From an accessibility perspective that's questionable -- and I don't mean the legally blind, just people like myself whose eyes are getting a bit older. This also means I don't particularly like adding background color (no matter how light) to text samples. --Guido On Tue, Mar 20, 2012 at 3:38 PM, Georg Brandl 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.) -- --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] Python install layout and the PATH on win32
On Wed, 21 Mar 2012 09:09:38 +1100, Mark Hammond
wrote:
> On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
> > I asked a question about this on IRC, to which the response was that
> > there were two main reasons to install python in c:\pythonxy:
> >
> > 1 - issues due to spaces ('Program Files') or non-ascii characters in
> > the path ('FiÈiere Program' on a Romanian windows). These issues are
> > supposed to be fixed by now (?).
> > 2 - issues due to permissions - installing python / packages in
> > %programfiles% may require administrator rights.
>
> Apart from personal preference (ie, I prefer the status quo here), the
> second issue is a bit of a killer. Even an administrator can not write
> to Program Files unless they are using an "elevated" process (ie,
> explicitly use "Run as Administrator" and confirm the prompt.
>
> This means that any installer wanting to write .py files into the Python
> install must be elevated, and any Python process wanting to generate
> .pyc files must also be elevated. So even if an installer does arrange
> elevation, unless that installer also compiles all .pyc and .pyo files
> at install time, Python would fail to generate the .pyc files on first
> use. While Python will probably fail silently and still continue to
> work, it will have a significant performance impact.
So windows requires admin privileges to install to Program Files, but
not to install to '/'? How novel. (You can perhaps tell that I'm
not a windoows user). My understanding, though, is that Python
does make a distinction between a system install of Python and
a per-user one, so I don't think your objection really applies.
That said, there is an open bug in the tracker about the insecurity
of a system install of python (exactly that the files are writable
by anyone). So that would have to be solved first. I'd say this
is definitely a separate issue from Van's discussion, and the *only*
reason one might want to tie them together at all is "well, we're
changing the directory layout anyway".
--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
On Tue, Mar 20, 2012 at 6:38 PM, 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 think regardless of the chosen style, giving the Python 3 docs a different look and feel also has a psychological benefit that might further encourage users to consider moving to Python 3. It could be a bit of a wake-up call. ___ 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 23:38:53 +0100, Georg Brandl 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. Hey, maybe you could make the sidebar only appear if the browser supports javascript? Then I'd never have to see it, and that I would consider "clean" :) Thanks for working on improving things. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32
On 21/03/2012 9:45 AM, R. David Murray wrote:
On Wed, 21 Mar 2012 09:09:38 +1100, Mark Hammond
wrote:
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
I asked a question about this on IRC, to which the response was that
there were two main reasons to install python in c:\pythonxy:
1 - issues due to spaces ('Program Files') or non-ascii characters in
the path ('Fișiere Program' on a Romanian windows). These issues are
supposed to be fixed by now (?).
2 - issues due to permissions - installing python / packages in
%programfiles% may require administrator rights.
Apart from personal preference (ie, I prefer the status quo here), the
second issue is a bit of a killer. Even an administrator can not write
to Program Files unless they are using an "elevated" process (ie,
explicitly use "Run as Administrator" and confirm the prompt.
This means that any installer wanting to write .py files into the Python
install must be elevated, and any Python process wanting to generate
.pyc files must also be elevated. So even if an installer does arrange
elevation, unless that installer also compiles all .pyc and .pyo files
at install time, Python would fail to generate the .pyc files on first
use. While Python will probably fail silently and still continue to
work, it will have a significant performance impact.
So windows requires admin privileges to install to Program Files, but
not to install to '/'? How novel. (You can perhaps tell that I'm
not a windoows user). My understanding, though, is that Python
does make a distinction between a system install of Python and
a per-user one, so I don't think your objection really applies.
I think it does. Consider I've installed Python as a "system install".
Now I want to install some other package - ideally that installer will
request elevation - all well and good - the .py files are installed.
However, next time I want to run Python, it will fail to generate the
.pyc files - even though I'm an administrator. I would need to
explicitly tell Python to execute "as administrator" (or run it from an
already elevated command-prompt) to have things work as expected. Thus,
the "usual" case would be that Python is unable to update any files in
its install directory.
If Python installed for a single user didn't install into Program Files
(which it probably couldn't do without an administrator providing
credentials anyway) then it wouldn't be a problem - but then we have
multiple possible default install locations, which sounds like more
trouble than it is worth...
That said, there is an open bug in the tracker about the insecurity
of a system install of python (exactly that the files are writable
by anyone). So that would have to be solved first. I'd say this
is definitely a separate issue from Van's discussion, and the *only*
reason one might want to tie them together at all is "well, we're
changing the directory layout anyway".
Agreed.
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] Python install layout and the PATH on win32
On 3/20/2012 4:25 PM, Mark Hammond wrote: I think it does. Consider I've installed Python as a "system install". Now I want to install some other package - ideally that installer will request elevation - all well and good - the .py files are installed. However, next time I want to run Python, it will fail to generate the .pyc files - even though I'm an administrator. I would need to explicitly tell Python to execute "as administrator" (or run it from an already elevated command-prompt) to have things work as expected. Thus, the "usual" case would be that Python is unable to update any files in its install directory. If Python installed for a single user didn't install into Program Files (which it probably couldn't do without an administrator providing credentials anyway) then it wouldn't be a problem - but then we have multiple possible default install locations, which sounds like more trouble than it is worth... That said, there is an open bug in the tracker about the insecurity of a system install of python (exactly that the files are writable by anyone). So that would have to be solved first. I'd say this is definitely a separate issue from Van's discussion, and the *only* reason one might want to tie them together at all is "well, we're changing the directory layout anyway". Indeed, the single user "place" isn't a single place, unless you consider the per-user $APPDATA environment variable sufficient to determine it (or the Windows API that returns the initial boot up value of $APPDATA/ %APPDATA%, which is the preferred technique for code). But it does solve the security problem (stuff in APPDATA is accessible only to a single login by default). So that might be justification for putting it there, for single users. For multi-user installs, %PROGRAMFILES% is appropriate, but, like I've heard some Linux distributions do, *.pyc might have to be prebuilt and installed along with Python (or generated during install, instead of waiting for first use). ___ 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/20/2012 06:45 PM, Guido van Rossum wrote: > Nice and clean, but looks too similar to newer Google properties... > Also I see that (like Google) you're falling for the fallacy of using > less contrast. From an accessibility perspective that's questionable > -- and I don't mean the legally blind, just people like myself whose > eyes are getting a bit older. This also means I don't particularly > like adding background color (no matter how light) to text samples. +1. Even make comments low-contrast defeats their purpose (italic works fine for that). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9pFmsACgkQ+gerLs4ltQ7fpwCeOY5p2HnqotHrWrN5vqsHfcsl 2EYAn3cnlemVO/RKavU3SC4w5b+q66S6 =Oryl -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
Hi Georg, On Tue, 20 Mar 2012 23:38:53 +0100 Georg Brandl 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. ___ 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 20Mar2012 15:45, Guido van Rossum wrote: | Nice and clean, but looks too similar to newer Google properties... | Also I see that (like Google) you're falling for the fallacy of using | less contrast. From an accessibility perspective that's questionable | -- and I don't mean the legally blind, just people like myself whose | eyes are getting a bit older. This also means I don't particularly | like adding background color (no matter how light) to text samples. Conversely, I like the text samples slightly shaded; I find a bare rectangle on the perimeter of a DIV just a tad more like noise, whereas a very slightly shaded block makes it very clear to me. I know it is a PITA, but how hard is it to make a tiny tiny CSS control block somewhere so a user can tune the style in coarse ways (i.e. tweak the properties of the class for shaded blocks)? I think the font choice in the new style is better; cleaner, less noisy, like a sans serif font versus a serifed font. So much so that I thought the new style used annoyingly more whitespace, but putting them side by side shows the new style to be more compact. Win win! One thing that bothers me about both styles is the fixed width text versus proportional size difference. Let me say in advance that I'm viewing both in Firefox on a Mac. To take an example, in the argparse module the opening sentence says "The argparse module". For me the word "argparse" is distinctly shorter in vertical height, which is a bit jarring. (the difference is smaller in the new style.) Is there a way to specify fonts that keeps this height attribute the same? Example screen shots (just those three words): http://dl.dropbox.com/u/2607515/screenshots/argparse-new1.png http://dl.dropbox.com/u/2607515/screenshots/argparse-old1.png Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ That's just the sort of bloody stupid name they would choose. - Reginald Mitchell, designer of the Spitfire ___ 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 20, 2012, at 5:37 PM, Antoine Pitrou wrote: > Georg Brandl 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. Raymond___ 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/20/2012 6:38 PM, Georg Brandl wrote: The current green on the front page is too heavy. Otherwise I prefer the old. I like the color on the index chart of the builtin-functions page. You un-bolded most (not all) of the entries and then are definitely too thin now. You unbolded the blue elsewhere and it is definitely harder for me to read. My eyesight does not correct to 20/20 and I have trouble reading many things, but the current docs work pretty well for me. -- 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] Python install layout and the PATH on win32
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. > > This is a good point. Who can make this call - Guido, or someone else? ___ 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/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. In text like ours with frequent long expressions, URLs, and the like, full justification is just an invitation to mangle the spacing of a paragraph. The paragraphs are also quite short and often interrupted by samples, lists, headings, and so on, losing the design advantage of a clean right edge anyway. Books, magazines, and newspapers look good with full justification, web pages do not. Can we switch to left-justified instead? --Ned. 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/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
Hi, 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. > > This is a good point. Who can make this call - Guido, or someone else? 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. 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 development . 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. 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] Python install layout and the PATH on win32
R. David Murray wrote: My understanding, though, is that Python does make a distinction between a system install of Python and a per-user one, so I don't think your objection really applies. Seems to me that for Python at least, the important distinction is not so much where the files are placed, but whether the registry entries are made machine-wide or user-local. -- 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] Playing with a new theme for the docs
On 20.03.2012 23:45, Guido van Rossum wrote: > Nice and clean, but looks too similar to newer Google properties... > Also I see that (like Google) you're falling for the fallacy of using > less contrast. From an accessibility perspective that's questionable > -- and I don't mean the legally blind, just people like myself whose > eyes are getting a bit older. This also means I don't particularly > like adding background color (no matter how light) to text samples. Well, to be fair, the current theme also has a lot of shading, and the text in the sidebar is at lower contrast too. But I can see that the main text should remain at as high contrast as possible. 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 00:17, R. David Murray wrote: > On Tue, 20 Mar 2012 23:38:53 +0100, Georg Brandl 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 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
