Re: [Python-Dev] Playing with a new theme for the docs
On Tue, Mar 20, 2012 at 3:55 PM, John O'Connor wrote: > 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. > +3 Of course you do realize that the only possible outcome of this thread which is *literally* about painting the docs bike shed is to have a row of dynamic "change my css theme" buttons somewhere with one for each person that has piped up in this thread. Which would lead to a stateful docs web server with cookie preferences on which css to default to for each and every viewer. This doesn't end well... ;) Good luck (and thanks for trying, I like seeing the new styles!) -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rename time.steady(strict=True) to time.monotonic()?
On Sat, Mar 24, 2012 at 00:36, Victor Stinner wrote: >> This seems like it should have been a PEP, or maybe should become a PEP. > > I replaced time.wallclock() by time.steady(strict=False) and > time.monotonic() by time.steady(strict=True). This change solved the > naming issue of time.wallclock(), but it was a bad idea to merge > monotonic() feature into time.steady(). It looks like everybody > agrees, am I wrong? Yes. As mentioned time.steady(i_mean_it=True) or time.steady(no_not_really=True) doesn't make any sense. Merging the methods may very well make sense, but it should then return a best case and have no flags. I think, as it has been hard to reach an agreement on this that the proposal to only make "stupid" functions that expose the system API's are the correct thing to do at the moment. > - time.time(): realtime, can be adjusted by the system administrator > (manually) or automatically by NTP Sure. > - time.clock(): monotonic clock on Windows, CPU time on UNIX This is for historical reasons, right, because this is what it is now? Would there be a problem in making time.clock() monotonic on Unix as well, if it exists? > - time.monotonic(): monotonic clock, its speed may or may not be > adjusted by NTP but it only goes forward, may raise an OSError > if the OS > has no monotonic clock, time.monotonic() will just not exist. Works for me, > - time.steady(): monotonic clock or the realtime clock, depending on > what is available on the platform (use monotonic in priority). may be > adjusted by NTP or the system administrator, may go backward. So it's time.may_or_may_not_be_steady() I don't mind the function, but the name should not be steady(). It's implementation is also so trivial that those who want a monotonic if it exists, but a normal clock otherwise, can simply just do > try: > return time.monotonic() > except (NotImplementError, OSError): > return time.time() themselves. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rename time.steady(strict=True) to time.monotonic()?
On Fri, 23 Mar 2012 22:38:19 -0500 Brian Curtin wrote: > On Fri, Mar 23, 2012 at 18:38, Yury Selivanov wrote: > > On 2012-03-23, at 7:28 PM, Brian Curtin wrote: > >> This seems like it should have been a PEP, or maybe should become a PEP. > > > > Why? AFAIK Victor just proposes to add two new functions: monotonic() and > > steady(). > > We just previously had "Drop time.monotonic() function, rename > time.wallclock() to time.steady()" checked in a few weeks ago, and now > we're renaming a variation on time.steady to time.monotonic? What's > the next move? > > I'm not paying close attention here but there's a lot of movement > going on. Figuring out the API before we get too deep is probably a > good idea. Agreed with Brian. Obviously the API needs further discussion, judging by Victor's own multiple changes of mind on the subject. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rename time.steady(strict=True) to time.monotonic()?
> Does this mean that there are circumstances where monotonic will work for a > while, but then fail? No. time.monotonic() always work or always fail. If monotonic() failed, steady() doesn't call it again. > Otherwise, we would only need to check monotonic once, when the time module > is first loaded, rather than every time it is called. Instead of the above: > > # global to the time module > try: > monotonic() > except (NameError, OSError): > steady = time > else: > steady = monotonic I implemented steady differently to avoid the need of calling monotonic at Python startup. Calling monotonic at startup would be an extra useless system call. 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] Rename time.steady(strict=True) to time.monotonic()?
>> - time.monotonic(): monotonic clock, its speed may or may not be >> adjusted by NTP but it only goes forward, may raise an OSError >> - time.steady(): monotonic clock or the realtime clock, depending on >> what is available on the platform (use monotonic in priority). may be >> adjusted by NTP or the system administrator, may go backward. >> > > I am surprised that a clock with the name time.steady() has a looser > definition than one called time.monotonic(). To my mind a steady clock is by > definition monotonic but a monotonic one may or may not be steady. Do you suggest another name? Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rename time.steady(strict=True) to time.monotonic()?
>> Oh, I was not aware of this issue. Do you suggest to not use >> QueryPerformanceCounter() on Windows to implement a monotonic clock? > > > I do not have an opinion on the best way to implement monotonic to guarantee > that it actually is monotonic. I opened an issue: http://bugs.python.org/issue14397 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 411 - request for pronouncement
On Fri, Mar 23, 2012 at 10:51, Eli Bendersky wrote: > The PEP received mostly positive feedback. The only undecided point is > where to specify that the package is provisional. Currently the PEP > mandates to specify it in the documentation and in the docstring. > Other suggestions were to put it in the code, either as a > __provisional__ attribute on the module, or collect all such modules > in a single sys.provisional list. I'm not sure what the usecase is for checking in code if a module is provisional or not. It doesn't seem useful, and risks being unmaintained, especially when the flag is on the module itself. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
On Sat, Mar 24, 2012 at 4:35 AM, PJ Eby wrote: > Just dumping things in a directory adjacent to the corresponding scripts is > the original virtualenv, and it still works just dandy -- most people just > don't *know* this. (And again, if there are tools out there that *don't* > support single-directory virtualenvs, the best answer is probably to fix > them.) Not to mention that CPython gained native support for that layout in 2.6 via __main__.py files (although I stuffed up and forgot to add it to the What's New before the release). I'll chime in on the -1 side here as well. If you want *easy* cross-platform execution of __main__, use the -m switch. I'm obviously biased, since I'm the original author and primary maintainer of that switch, but it just makes all these problems with cross-platform questions and running from an installed copy vs running from source *go away*. Indeed, avoiding such cross-platform inconsistencies with regards to the location of stdlib modules was one of the major arguments in favour of adding the original incarnation of the switch way back in Python 2.4. To run the main clients (one for repo management, one for Django site management) in my current work project, I use "python -m pulpdist.manage_repos" and "python -m pulpdist.manage_site". It works from a source checkout (so long as I cd into src/ first), on an installed version, in a virtualenv, anywhere. I can easily run it on a different Python version just by changing the version I invoke. The commands would probably also work on at least Mac OS X and maybe even Windows (although I've never actually tried either of those, since PulpDist is targeted specifically at Linux systems). I may get around to installing at least the repo management client as a real script some day (since it will be more convenient for system administrators that way), but direct execution will never be the main way of executing it from a source checkout. So Van's proposal still smacks too much to me of change for change's sake. If you want an execution mechanism that is completely consistent across platforms (including virtual environments), then "-m" already exists. For direct execution, the proposal trades cross-version inconsistencies for cross-platform consistency. When we *already have* a consistent cross-platform mechanism in -m, the inevitable disruption involved in changing the Windows layout seems very hard to justify. 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] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
On Sat, Mar 24, 2012 at 07:19, Nick Coghlan wrote: > On Sat, Mar 24, 2012 at 4:35 AM, PJ Eby wrote: >> Just dumping things in a directory adjacent to the corresponding scripts is >> the original virtualenv, and it still works just dandy -- most people just >> don't *know* this. (And again, if there are tools out there that *don't* >> support single-directory virtualenvs, the best answer is probably to fix >> them.) > > Not to mention that CPython gained native support for that layout in > 2.6 via __main__.py files (although I stuffed up and forgot to add it > to the What's New before the release). > > I'll chime in on the -1 side here as well. If you want *easy* > cross-platform execution of __main__, use the -m switch. I love the -m option but what does it have to do with unifying the install layout? One is about executing __main__ and one is about a directory structure. > Indeed, avoiding such cross-platform inconsistencies with > regards to the location of stdlib modules was one of the major > arguments in favour of adding the original incarnation of the switch > way back in Python 2.4. Ok, so it is about directory structure, but about the standard library. Since part of this proposal is about Scripts vs. bin, how does -m help you there? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rename time.steady(strict=True) to time.monotonic()?
On Sat, Mar 24, 2012 at 4:38 AM, Brian Curtin wrote: > On Fri, Mar 23, 2012 at 18:38, Yury Selivanov wrote: >> On 2012-03-23, at 7:28 PM, Brian Curtin wrote: >>> This seems like it should have been a PEP, or maybe should become a PEP. >> >> Why? AFAIK Victor just proposes to add two new functions: monotonic() and >> steady(). Need for PEPs is not determined by volume of content, but by amount of controversy and lack of clarity. Isn't it obvious that there's quite a bit of disagreement about the definitions of "monotonic" and "steady", and about whether these functions should be what they say they are or "best effort", and so on? +1 for a PEP. > We just previously had "Drop time.monotonic() function, rename > time.wallclock() to time.steady()" checked in a few weeks ago, and now > we're renaming a variation on time.steady to time.monotonic? What's > the next move? > > I'm not paying close attention here but there's a lot of movement > going on. Figuring out the API before we get too deep is probably a > good idea. I have been following the thread but don't have the technical knowledge to be sure what's going on. What I have decided is that I won't be using any function named time.steady() or time.monotonic() because neither one seems likely to guarantee the property it's named for, and by the time I have a use case (I don't have one now, I'm just an habitual lurker) I'll have forgotten the conclusion of this thread, but not the deep feelings of FUD. To get me on board (not that there's any particular reason you should care, but just in case), you're going to need to respect EIBTI. By that I mean that a monotonic clock is monotonic, and if not available at instantiation, an Exception will be raised. Similarly for a steady clock. There is no such thing as "best effort" here for clocks with these names. The default clock should be best effort. If that is for some reason "expensive", then there should be a "time.windup_clock()" to provide an unreliable resource- conserving clock. FWIW, I understand that (1) A monotonic clock is one that never goes backwards. If precision allows, it should always go forwards (ie, repeated calls should always produce strictly larger time values). (2) A steady clock is strictly monotonic, and when a discrepancy against "true time" is detected (however that might happen), it slews its visible clock until the discrepancy is eliminated, so that one clock second always means something "close" to one second. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rename time.steady(strict=True) to time.monotonic()?
> I don't see what is the use case requiring a is truly monotonic clock. A clock that is purely monotonic may not be useful. However, people typically imply that it will have a certain minimum progress (seconds advanced/real seconds passed). Then you can use it for timeouts. 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 Sat, Mar 24, 2012 at 1:32 AM, Greg Ewing wrote: > PJ Eby wrote: > > Weird - I have the exact *opposite* problem, where I have to resize my >> window because somebody *didn't* set their text max-width sanely (to a >> reasonable value based on ems instead of pixels), and I have nearly 1920 >> pixels of raw text spanning my screen. >> > > If you don't want 1920-pixel-wide text, why make your > browser window that large? > Not every tab in my browser is text for reading; some are apps that need the extra horizontal space. That is, they have more than one column of text or data -- but no individual column spans anywhere near the full width. (Google Docs, for example, shows me two pages at a time when I'm reading a PDF.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
By dodging the issue entirely - anything I might want to regularly run from a source checkout I execute with -m. It gets sys.path right automatically and I don't need to care about platform specific executable naming conventions. -- Sent from my phone, thus the relative brevity :) ___ 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
PJ Eby writes: > On Sat, Mar 24, 2012 at 1:32 AM, Greg Ewing > wrote: > > > If you don't want 1920-pixel-wide text, why make your browser window > > that large? > > Not every tab in my browser is text for reading; some are apps that > need the extra horizontal space. So, again, why make your browser window *for reading text* that large? You have control over how large your window size is, and if you have purposes so different that they demand different widths, then you can easily make different-width windows. Everyone has different needs for how large the text should be and how much of it should go across the window. Every one of us is in a minority when it comes to those needs; that's exactly what a configuration setting is good for. It's madness to expect web designers to hobble the flexibility of a web page to cater preferentially for one minority over others. -- \ “Come on Milhouse, there’s no such thing as a soul! It’s just | `\ something they made up to scare kids, like the Boogie Man or | _o__) Michael Jackson.” —Bart, _The Simpsons_ | 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 3/24/2012 5:41 PM, Ben Finney wrote: It's madness to expect web designers to hobble the flexibility of a web page to cater preferentially for one minority over others. But largely, the 99% that makes the rest of them look bad, do, in fact, do exactly that. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Playing with a new theme for the docs, iteration 2
Here's another try, mainly with default browser font size, more contrast and collapsible sidebar again: http://www.python.org/~gbrandl/build/html2/ I've also added a little questionable gimmick to the sidebar (when you collapse it and expand it again, the content is shown at your current scroll location). Have fun! Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
On Sun, Mar 25, 2012 at 1:41 AM, Ben Finney wrote: > PJ Eby writes: >> Not every tab in my browser is text for reading; some are apps that >> need the extra horizontal space. > > So, again, why make your browser window *for reading text* that large? Because he prefers controlling the content viewed by selecting tabs rather than selecting windows, no doubt. But since he's arguing the other end in the directory layout thread (where he says there are many special ways to invoke Python so that having different layouts on different platforms is easy to work around), I can't give much weight to his preference here. Anyway, CSS is supposed to allow the user to impose such constraints herself, so Philip "should" do so with a local style, rather than ask designers to do it globally. > It's madness to expect web designers to hobble the flexibility of a web > page to cater preferentially for one minority over others. No, as Glenn points out, designers (I wouldn't call them *web* designers since they clearly have no intention of taking advantage of the power of the web in design, even if they incorporate links in their pages!) frequently do exactly that. (The minority of one in question being the designer himself!) So it's rational to expect it. :-( However, I believe that CSS also gives us the power to undo such bloodymindedness, though I've never gone to the trouble of learning how. Steve ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
