Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
Am 02.04.2012 00:31, schrieb Matěj Cepl: On 1.4.2012 23:46, Brian Curtin wrote: For what reason? Are the git or bzr files causing issues on HG? No, but wrong .gitignore causes issues with git repo obtained via hg-fast-import. If it is meant as an intentional sabotage of using git (and bzr) for cpython, then that's the only explanation I can understand, otherwise it doesn't make sense to me why these files are in HG repository at all. Sabotage, most certainly. 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] .{git,bzr}ignore in cpython HG repo
On 02/04/2012 07:03, Martin v. Löwis wrote: Am 02.04.2012 00:31, schrieb Matěj Cepl: On 1.4.2012 23:46, Brian Curtin wrote: For what reason? Are the git or bzr files causing issues on HG? No, but wrong .gitignore causes issues with git repo obtained via hg-fast-import. If it is meant as an intentional sabotage of using git (and bzr) for cpython, then that's the only explanation I can understand, otherwise it doesn't make sense to me why these files are in HG repository at all. Sabotage, most certainly. I had to laugh. It's the deadpan delivery. 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] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
On 30 March 2012 21:52, Guido van Rossum gu...@python.org wrote: Oh dear. I really want to say that 15 ms is good enough. Some possible exceptions I can think of: - Profiling. But this really wants to measure CPU time anyways, and it already uses a variety of hacks and heuristics to pick the best timer, so I don't really care. That depends on what you're profiling. If you're profiling CPU bound algorithms then yes CPU time is better. But if your trying to profile/measure hardware device/comms performance for example then CPU time is of no interest. There, on windows the 15ms resolution of time.time makes it useless. For some reason I always forget this and sit looking at trace outs for 5 minutes wondering why everything takes either 0, 15, or 30ms. For nearly all my use cases I'm not terribly interested in monotonicity, or stability in suspend/resume states so I won't give my opinions on thiose (though I can see they are good things and can well imagine needing them one day), I just want an easy way of getting at least micro second resolution cross platform. I don't mind particularly what you call it but FWIW 'highres' seems a bit odd to me. It seems that highres is likely to seem lowres one day, and then you need to add higherres() and then evenhigherthanthatres(). I would go with microtime(), or nanotime() it doesn't make any promises about anything other than the resolution. Sam ___ Python-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] .{git,bzr}ignore in cpython HG repo
On 2.4.2012 05:26, Scott Dial wrote: Create an issue on the bug tracker. In the meantime, you can either commit the change to your clone, or you can put your ignores into .git/info/exclude. No reason to be so sore about it, since Git lets you have your own ignore file without requiring it be a tracked file. And yes, I am sorry for the tone of my original post. The fact I didn't understand the reason, doesn't excuse me. Matěj ___ Python-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] .{git,bzr}ignore in cpython HG repo
On 2.4.2012 00:52, Guido van Rossum wrote: Please file a bug to get this reviewed and checked in. OK, I don't agree with the reasoning, but I willingly submit to BDFL ;) http://bugs.python.org/issue14472 Matěj ___ Python-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] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
I've just finished sketching out a skeleton here: https://bitbucket.org/cameron_simpson/css/src/fb476fcdcfce/lib/python/cs/clockutils.py get_clock() returns None if no clock has the requested flags, whereas I expected an exception (LookupError or NotImplementError?). get_clock() doesn't remember if a clock works or not (if it raises an OSError) and does not fallback to the next clock on error. See pseudo-codes in the PEP 418. The idea of flags attached to each clock is interesting, but I don't like the need of different list of clocks. Should I use MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and high-resolution clock? It would be simpler to have only one global and *private* list. If you have only one list of clocks, how do sort the list to get QueryPerformanceCounter when the user asks for highres and GetTickCount when the user asks for monotonic? The if clock.flags flags == flags: test in get_clock() is maybe not enough. I suppose that we would have the following flags for Windows functions: QueryPerformanceCounter.flags = T_HIRES GetTickCount.flags = T_MONOTONIC | T_STEADY (or maybe QueryPerformanceCounter.flags = T_HIRES | T_MONOTONIC ?) monotonic_clock() should maybe try to get a clock using the following list of conditions: - T_MONOTONIC | T_STEADY - T_MONOTONIC | T_HIGHRES - T_MONOTONIC The T_HIGHRES flag in unclear, even in the PEP. According to the PEP, any monotonic clock is considered as a high-resolution clock. Do you agree? So we would have: GetTickCount.flags = T_MONOTONIC | T_STEADY | T_HIGHRES Even if GetTickCount has only an accuracy of 15 ms :-/ Can list please give the list of flags of each clocks listed in the PEP? Only clocks used for time.time, time.monotonic and time.highres (not process and thread clocks nor QueryUnbiasedInterruptTime). # get a clock object - often a singleton under the hood T = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_STEADY|T_HIRES) # what kind of clock did I get? print T.flags # get the current time now = T.now The API looks much more complex than the API proposed in PEP 418 just to get the time. You have to call a function to get a function, and then call the function, instead of just calling a function directly. Instead of returning an object with a now() method, I would prefer to get directly the function getting time, and another function to get metadata of the clock. This removes policy from the library functions and makes it both simple and obvious in the user's calling code, and also makes it possible for the user to inspect the clock and find out what quality/flavour of clock they got. I'm not sure that users understand correctly differences between all these clocks and are able to use your API correctly. How should I combinese these 3 flags (T_HIRES, T_MONOTONIC and T_STEADY)? Can I use any combinaison? Which flags are portable? Or should I always use an explicit fallback to ensure getting a clock on any platform? Could you please update your code according to my remarks? I will try to integrate it into the PEP. A PEP should list all alternatives! 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] .{git,bzr}ignore in cpython HG repo
On Sun, 1 Apr 2012 19:44:00 -0500 Brian Curtin br...@python.org wrote: On Sun, Apr 1, 2012 at 17:31, Matěj Cepl mc...@redhat.com wrote: On 1.4.2012 23:46, Brian Curtin wrote: For what reason? Are the git or bzr files causing issues on HG? No, but wrong .gitignore causes issues with git repo obtained via hg-fast-import. If it is meant as an intentional sabotage of using git (and bzr) for cpython, then that's the only explanation I can understand, otherwise it doesn't make sense to me why these files are in HG repository at all. Then you won't understand. Sometimes things get out of date when they aren't used or maintained. You're welcome to fix the problem if you're a Git user, as suggested earlier. That said, these files will always be outdated, so we might as well remove them so that at least git / bzr users don't get confused. 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] .{git,bzr}ignore in cpython HG repo
Antoine Pitrou, 02.04.2012 13:50: On Sun, 1 Apr 2012 19:44:00 -0500 Brian Curtin wrote: On Sun, Apr 1, 2012 at 17:31, Matěj Cepl wrote: On 1.4.2012 23:46, Brian Curtin wrote: For what reason? Are the git or bzr files causing issues on HG? No, but wrong .gitignore causes issues with git repo obtained via hg-fast-import. If it is meant as an intentional sabotage of using git (and bzr) for cpython, then that's the only explanation I can understand, otherwise it doesn't make sense to me why these files are in HG repository at all. Then you won't understand. Sometimes things get out of date when they aren't used or maintained. You're welcome to fix the problem if you're a Git user, as suggested earlier. That said, these files will always be outdated, so we might as well remove them so that at least git / bzr users don't get confused. How often is anything added to the .hgignore file? I doubt that these files will sufficiently always be outdated to be unhelpful. Stefan ___ Python-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] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
On Mon, Apr 2, 2012 at 2:31 AM, Sam Partington sam.parting...@gmail.com wrote: On 30 March 2012 21:52, Guido van Rossum gu...@python.org wrote: Oh dear. I really want to say that 15 ms is good enough. Some possible exceptions I can think of: - Profiling. But this really wants to measure CPU time anyways, and it already uses a variety of hacks and heuristics to pick the best timer, so I don't really care. That depends on what you're profiling. If you're profiling CPU bound algorithms then yes CPU time is better. But if your trying to profile/measure hardware device/comms performance for example then CPU time is of no interest. There, on windows the 15ms resolution of time.time makes it useless. For some reason I always forget this and sit looking at trace outs for 5 minutes wondering why everything takes either 0, 15, or 30ms. For nearly all my use cases I'm not terribly interested in monotonicity, or stability in suspend/resume states so I won't give my opinions on thiose (though I can see they are good things and can well imagine needing them one day), I just want an easy way of getting at least micro second resolution cross platform. I don't mind particularly what you call it but FWIW 'highres' seems a bit odd to me. It seems that highres is likely to seem lowres one day, and then you need to add higherres() and then evenhigherthanthatres(). I would go with microtime(), or nanotime() it doesn't make any promises about anything other than the resolution. You're being altogether too reasonable about it. :-) People keep asking for a clock that has nanosecond precision and yet will tell time accurately for centuries, without ever skipping forward or backward... -- --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] .{git,bzr}ignore in cpython HG repo
On Mon, Apr 2, 2012 at 9:50 PM, Antoine Pitrou solip...@pitrou.net wrote: That said, these files will always be outdated, so we might as well remove them so that at least git / bzr users don't get confused. Apologies for what may be a stupid suggestion, but is it possible to write a script that generates .gitignore and .bzrignore from .hgignore? That ought to solve the problem - take the former two out of the repository, and everyone who wants to use git or bzr can simply generate them on requirement. Chris Angelico ___ Python-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] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
At least on some versions of Windows (e.g. XP) the QueryPerformanceCounter()-API is more or less only a stub around a call to RDTSC which in turn varies in frequency on (at least) Intel Pentium 4, Pentium M and Xeon processors (bound to the current clock frequencies). ___ Python-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] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
-Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Cameron Simpson Sent: 30. mars 2012 21:43 There seem to be a few competing features for clocks that people want: - monotonic - never going backward at all - high resolution - no steps no steps is something unquantifiable. All time has steps in it. What you mean here is no 'noise'. And this is also never actually achievable. A clock that ticks forwards, but sometimes stops some and then ticks some more, is simply a clock with a lower resolution on average than what can be observed for certain time periods. It befuddles me somewhat how complicated you are making all of this. Simply provide the best high resolution, non-backwards ticking, performance timer that the platform provides, and don't try to make promises about unquantifiable things such as 'steps'. You can do this simply using QPC on windows and enforcing the forward ticking using a static local. Simply promise that this is a forward ticking clock with the highest resolution and lowest noise available for the platform and make no other guarantees, other than perhaps suggesting that this might not be used reliably for benchmarking on older os/hardware platforms. K ___ Python-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] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
You seem to have missed the episode where I explained that caching the last value in order to avoid going backwards doesn't work -- at least not if the cached value is internal to the API implementation. 2012/4/2 Kristján Valur Jónsson krist...@ccpgames.com: -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Cameron Simpson Sent: 30. mars 2012 21:43 There seem to be a few competing features for clocks that people want: - monotonic - never going backward at all - high resolution - no steps no steps is something unquantifiable. All time has steps in it. What you mean here is no 'noise'. And this is also never actually achievable. A clock that ticks forwards, but sometimes stops some and then ticks some more, is simply a clock with a lower resolution on average than what can be observed for certain time periods. It befuddles me somewhat how complicated you are making all of this. Simply provide the best high resolution, non-backwards ticking, performance timer that the platform provides, and don't try to make promises about unquantifiable things such as 'steps'. You can do this simply using QPC on windows and enforcing the forward ticking using a static local. Simply promise that this is a forward ticking clock with the highest resolution and lowest noise available for the platform and make no other guarantees, other than perhaps suggesting that this might not be used reliably for benchmarking on older os/hardware platforms. K -- --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] an alternative to embedding policy in PEP 418
On 4/2/2012 4:37 AM, Victor Stinner wrote: The API looks much more complex than the API proposed in PEP 418 just to get the time. You have to call a function to get a function, and then call the function, instead of just calling a function directly. Instead of returning an object with a now() method, I would prefer to get directly the function getting time, and another function to get metadata of the clock. If there are more than two clocks, with different characteristics, no API is going to be both simple to use and fast to call. If there are more than two clocks, with different characteristics, then having an API to get the right API to call to get a time seems very natural to me. One thing I don't like about the idea of fallback being buried under some API is that the efficiency of that API on each call must be less than the efficiency of directly calling an API to get a single clock's time. For frequently called high resolution clocks, this is more burdensome than infrequently called clocks yet those seem to be the ones for which fallbacks are proposed, because of potential unavailability. Having properties on each of various different clock functions is cumbersome... the user code must know about each clock, how to obtain the properties, and then how to choose one for use... And how will one be chosen for use? Under the assumption that all return some sort of timestamp and take no parameters, a local name will be assigned to the clock of interest: if ...: myTime = os.monotonous elif ...: myTime = os.evenhigherres ... elif ...: myTime = time. time so that myTime can be use throughout. Cameron's API hides all the names of the clocks, and instead offers to do the conditional logic for you, and the resultant API returned can be directly assigned to myTime, and the logic for choosing a clock deals only with the properties of the clock, not the names of the APIs, which is a nice abstraction. There would not even be a need to document the actual names of the APIs for each individual clock, except that probably some folks would want to directly code them, especially if they are not interested in cross-platform work. The only thing I'm not so sure about: can the properties be described by flags? Might it not be better to have an API that allows specification of minimum resolution, in terms of fractional seconds? Perhaps other properties suffice as flags, but perhaps not resolution. ___ Python-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] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
On Apr 2, 2012, at 10:39 AM, Kristján Valur Jónsson wrote: no steps is something unquantifiable. All time has steps in it. No steps means something very specific when referring to time APIs. As I recently explained here: http://article.gmane.org/gmane.comp.python.devel/131487/. -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] .{git,bzr}ignore in cpython HG repo
On 4/2/2012 11:03 AM, Chris Angelico wrote: On Mon, Apr 2, 2012 at 9:50 PM, Antoine Pitrou solip...@pitrou.net wrote: That said, these files will always be outdated, so we might as well remove them so that at least git / bzr users don't get confused. Apologies for what may be a stupid suggestion, but is it possible to write a script that generates .gitignore and .bzrignore from .hgignore? That ought to solve the problem - take the former two out of the repository, and everyone who wants to use git or bzr can simply generate them on requirement. In general, Hg's ignore files are more expressive (regex and globbing) than Git's ignore files (globbing only). Our .hgignore file has regex rules, but if someone was so inclined, they could expand those rules based on their current HEAD. I do not know if such a tool already exists in the wild. -- Scott Dial sc...@scottdial.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
On 02Apr2012 13:37, Victor Stinner victor.stin...@gmail.com wrote: | I've just finished sketching out a skeleton here: | https://bitbucket.org/cameron_simpson/css/src/fb476fcdcfce/lib/python/cs/clockutils.py | | get_clock() returns None if no clock has the requested flags, whereas | I expected an exception (LookupError or NotImplementError?). That is deliberate. People can easily write fallback like this: clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC) With exceptions one gets a complicated try/except/else chain that is much harder to read. With a second fallback the try/except gets even worse. If one wants an exception it is easy to follow up with: if not clock: raise RunTimeError(no suitable clocks on offer on this platform) | get_clock() doesn't remember if a clock works or not (if it raises an | OSError) and does not fallback to the next clock on error. See | pseudo-codes in the PEP 418. I presume the available clocks are all deduced from the platform. Your pseudo code checks for OSError at fetch-the-clock time. I expect that to occur once when the module is loaded, purely to populate the table of avaiable platform clocks. If you are concerned about clocks being available/unavailable at different times (unplugging the GPS peripheral? just guessing here) that will have to raise OSError during the now() call (assuming the clock even exposes the failure; IMO it should when now() is called). | The idea of flags attached to each clock is interesting, but I don't | like the need of different list of clocks. There's no need, just quality of implementation for the monotonic()/hires() convenience calls, which express the (hoped to be common) policy of what clock to offer for each. We've just had pages upon pages of discussion about what clock to offer for the rather bald monotonic() (et al) calls. The ordering of the MONTONIC_CLOCKS list would express the result of that discussion, in that the better clocks come first. | Should I use | MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and | high-resolution clock? Note that you don't need to provide a clock list at all; get_clock(0 will use ALL_CLOCKS by default, and hires() and monotonic() should each have their own default list. I'll put in montonic() and montonic_clock(clocklist=MONOTONIC_CLOCKS) into the skeleton to make this clear; I see I've omitted them. Regarding the choice itself: as the _caller_ (not the library author), you must decide what you want most. You're already planning offering monotonic() and hires() calls without my proposal! Taking your query Should I use MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and high-resolution clock is _already_ a problem. Of course you must call monotonic() or hires() first under the current scheme, and must answer this question anyway. Do you prefer hires? Use it first! No preference? Then the question does not matter. If I, as the caller, have a preference then it is obvious what to use. If I do not have a preference then I can just call get_clock() with both flags and then arbitrarily fall back to hires() or monotonic() if that does not work. | It would be simpler to have only one global and | *private* list. No. No no no no no! The whole point is to let the user be _able_ to control the choices to a fair degree without platform special knowledge. The lists are deliberately _optional_ parameters and anyway hidden in the hires() and monotonic() convenince functions; the user does not need to care about them. But the picky user may! The lists align exactly one to one with the feature flags, so there is no special knowledge present here that is not already implicit in publishing the feature flags. | If you have only one list of clocks, how do sort the list to get | QueryPerformanceCounter when the user asks for highres and | GetTickCount when the user asks for monotonic? This is exactly why there are supposed to be different lists. You have just argued against your objection above. | The if clock.flags | flags == flags: test in get_clock() is maybe not enough. I suppose | that we would have the following flags for Windows functions: | | QueryPerformanceCounter.flags = T_HIRES | GetTickCount.flags = T_MONOTONIC | T_STEADY | | (or maybe QueryPerformanceCounter.flags = T_HIRES | T_MONOTONIC ?) Obviously these depend on the clock characteristics. Is QueryPerformanceCounter monotonic? | monotonic_clock() should maybe try to get a clock using the following | list of conditions: | - T_MONOTONIC | T_STEADY | - T_MONOTONIC | T_HIGHRES | - T_MONOTONIC Sure, seems reasonable. That is library internal policy _for the convenince monotonic() function()_. | The T_HIGHRES flag in unclear, even in the PEP. According to the PEP, | any monotonic clock is considered as a high-resolution clock. Do you | agree? Not particularly. I easily can imagine a clock with one second resolution hich was monotonic. I would not expect it to have the
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
On Mon, Apr 2, 2012 at 9:50 PM, Antoine Pitrou solip...@pitrou.net wrote: That said, these files will always be outdated, so we might as well remove them so that at least git / bzr users don't get confused. Given that they were originally *added* by core devs that are (or were) using git/bzr for their own local development, I don't think it's quite that simple. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
On 03Apr2012 07:38, I wrote: | On 02Apr2012 13:37, Victor Stinner victor.stin...@gmail.com wrote: | | Could you please update your code according to my remarks? I will try | | to integrate it into the PEP. A PEP should list all alternatives! New code here: https://bitbucket.org/cameron_simpson/css/src/91848af8663b/lib/python/cs/clockutils.py Diff: https://bitbucket.org/cameron_simpson/css/changeset/91848af8663b Changelog: updates based on suggestions from Victor Stinner: flat API calls to get time directly, make now() a method instead of a property, default flags for get_clock(), adjust hr_clock() to hires_clock(0 for consistency. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Q: How does a hacker fix a function which doesn't work for all of the elements in its domain? A: He changes the domain. - Rich Wareham rj...@hermes.cam.ac.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] an alternative to embedding policy in PEP 418
On 02Apr2012 10:44, Glenn Linderman v+pyt...@g.nevcal.com wrote: | On 4/2/2012 4:37 AM, Victor Stinner wrote: | The API looks much more complex than the API proposed in PEP 418 just | to get the time. You have to call a function to get a function, and | then call the function, instead of just calling a function directly. | | Instead of returning an object with a now() method, I would prefer to | get directly the function getting time, and another function to get | metadata of the clock. | | If there are more than two clocks, with different characteristics, no | API is going to be both simple to use and fast to call. | | If there are more than two clocks, with different characteristics, then | having an API to get the right API to call to get a time seems very | natural to me. It is, though Victor's point about offering the very easy to use API is valid. The new code has the flat monotonic() et al calls as well. | One thing I don't like about the idea of fallback being buried under | some API is that the efficiency of that API on each call must be less | than the efficiency of directly calling an API to get a single clock's | time. For frequently called high resolution clocks, this is more | burdensome than infrequently called clocks yet those seem to be the | ones for which fallbacks are proposed, because of potential unavailability. I hadn't thought about that, but it isn't actually a big deal. The overhead isn't zero, but in order to always use the _same_ clock to return hires() (for example) the library has to cache the clock lookup anyway. Current clockutils.py skeleton here: https://bitbucket.org/cameron_simpson/css/src/91848af8663b/lib/python/cs/clockutils.py does so. | The only thing I'm not so sure about: can the properties be described by | flags? Might it not be better to have an API that allows specification | of minimum resolution, in terms of fractional seconds? Perhaps other | properties suffice as flags, but perhaps not resolution. It sounds nice, but there are some difficulties. Firstly, the (currently just 3) flags were chosen to map to the three features sought (in various cobinations) for clocks. Once you start requesting precision (a totally reasonable desire, BTW) you also want to request degree of slew (since steady is a tunabe term) and so forth. And what for clocks that have variable precision (I'm imaging here a clock which really is a float, and for large times (in the far future) can't return the sane resolution because of the size of a float. The concern is valid though. I could imagine beefing up the clock object metadata with .epoch (can be None!), precision (function of float width versus clock return value epislon), epsilon (your fraction of a second parameter). Of course, for some clocks any of these might be None. Then the truly concerned user iterates over the available clocks with the desired coarse flags, inspecting each closely for precision or whatever. Easy enough to tweak get_clock() to take an optional all_clocks=False parameter to return all matching clocks in an iterable instead of (the first match or None). Or the user could reach directly for one of the clock lists. cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Craft, n. A fool's substitute for brains. - The Devil's Dictionary ___ Python-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] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
On 03Apr2012 07:38, I wrote: | On 02Apr2012 13:37, Victor Stinner victor.stin...@gmail.com wrote: | | Should I use | | MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and | | high-resolution clock? | | Note that you don't need to provide a clock list at all; get_clock(0 | will use ALL_CLOCKS by default, and hires() and monotonic() should each | have their own default list. [...] | | It would be simpler to have only one global and | | *private* list. [...] | The whole point is to let the user be _able_ to control the choices to a | fair degree without platform special knowledge. On some reflection I may lean a little more Victor's way here: I am still very much of the opinion that there should be multiple clock lists so that hires() can offer the better hires clocks first and so forth. However, perhaps I misunderstood and he was asking if he needed to name a list to get a hires clock etc. This intent is not to need to, via the convenience functions. Accordingly, maybe the list names needn't be published, and may complicate the published interface even though they're one to one with the flags. It would certainly up the ante slightly f we added more flags some time later. (For example, I think any synthetic clocks such as the caching example in the skeleton should probably have a SYNTHETIC flag. You might never ask for it, but you should be able to check for it. (I personally suspect some of the OS clocks are themselves synthetic, but no matter...) The flip side of this of course is that if the list names are private then the get_clock() and hires() etc functions almost mandatorially need the optional all_clocks=False parameter mooted in a sibling post; the really picky user needs a way to iterate over the available clocks to make a fine grained decision. On example would be to ask for monotonic clocks but omit synthetic ones (there's a synthetic clock in the skeleton though I don't partiularly expect one in reality - that really is better in a broader *utils module; I also do NOT want to get into complicated parameters to say these flags but not _those_ flags and so forth for other metadata. And again, an external module offering synthetic clocks could easily want to be able to fetch the existing and augument the list with its own, then use that with the get_clock() interfaces. So in short I think: - there should be, internally at least, multiple lists for quality of returned result - there should be a way to iterate over the available clocks, probably via an all_clocks paramater instead of a public list name Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ There is hopeful symbolism in the fact that flags do not wave in a vacuum. - Arthur C. Clarke ___ Python-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] .{git,bzr}ignore in cpython HG repo
On Tue, 3 Apr 2012 07:43:20 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Mon, Apr 2, 2012 at 9:50 PM, Antoine Pitrou solip...@pitrou.net wrote: That said, these files will always be outdated, so we might as well remove them so that at least git / bzr users don't get confused. Given that they were originally *added* by core devs that are (or were) using git/bzr for their own local development, I don't think it's quite that simple. Wasn't it back when SVN was still our official VCS, though? I don't think Barry still uses bzr, and who ever used git to manage their patches against the CPython repo? 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] an alternative to embedding policy in PEP 418
On Tue, Apr 3, 2012 at 3:44 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote: One thing I don't like about the idea of fallback being buried under some API is that the efficiency of that API on each call must be less than the efficiency of directly calling an API to get a single clock's time. No, that's a misunderstanding of the fallback mechanism. The fallback happens when the time module is initialised, not on every call. Once the appropriate clock has been selected during module initialisation, it is invoked directly at call time. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] an alternative to embedding policy in PEP 418
On 4/2/2012 2:40 PM, Nick Coghlan wrote: On Tue, Apr 3, 2012 at 3:44 AM, Glenn Lindermanv+pyt...@g.nevcal.com wrote: One thing I don't like about the idea of fallback being buried under some API is that the efficiency of that API on each call must be less than the efficiency of directly calling an API to get a single clock's time. No, that's a misunderstanding of the fallback mechanism. The fallback happens when the time module is initialised, not on every call. Once the appropriate clock has been selected during module initialisation, it is invoked directly at call time. Nick, I would hope that is how the fallback mechanism would be coded, but I'm pretty sure I've seen other comments in this thread that implied otherwise. But please don't ask me to find them, this thread is huge. Glenn ___ Python-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] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
On 03Apr2012 07:51, I wrote: | Changelog: updates based on suggestions from Victor Stinner: flat API | calls to get time directly, make now() a method instead of a property, | default flags for get_clock(), adjust hr_clock() to hires_clock(0 for | consistency. BTW, I'd also happily change T_HIRES to HIRES and so forth. They're hard to type and read at present. The prefix is a hangover from old C coding habits, with no namespaces. -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ If you don't live on the edge, you're taking up too much space. - t-shirt ___ Python-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] .{git,bzr}ignore in cpython HG repo
On Tue, 03 Apr 2012 00:44:32 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 3 Apr 2012 07:43:20 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Mon, Apr 2, 2012 at 9:50 PM, Antoine Pitrou solip...@pitrou.net wrote: That said, these files will always be outdated, so we might as well remove them so that at least git / bzr users don't get confused. Given that they were originally *added* by core devs that are (or were) using git/bzr for their own local development, I don't think it's quite that simple. Wasn't it back when SVN was still our official VCS, though? I don't think Barry still uses bzr, and who ever used git to manage their patches against the CPython repo? That's my memory, too. I have to laugh at the claim that Barry doesn't use bzr. (But yeah, I know what you mean, I think he does use hg now for cpython development.) I think Benjamin was the one who used git, but I'm probably misremembering. --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] an alternative to embedding policy in PEP 418
On 02Apr2012 14:59, Glenn Linderman v+pyt...@g.nevcal.com wrote: | On 4/2/2012 2:40 PM, Nick Coghlan wrote: | On Tue, Apr 3, 2012 at 3:44 AM, Glenn Lindermanv+pyt...@g.nevcal.com wrote: |One thing I don't like about the idea of fallback being buried under some |API is that the efficiency of that API on each call must be less than the |efficiency of directly calling an API to get a single clock's time. | No, that's a misunderstanding of the fallback mechanism. The fallback | happens when the time module is initialised, not on every call. Once | the appropriate clock has been selected during module initialisation, | it is invoked directly at call time. | | I would hope that is how the fallback mechanism would be coded, but I'm | pretty sure I've seen other comments in this thread that implied | otherwise. But please don't ask me to find them, this thread is huge. The idea of falling back to different clocks on the fly on different calls got a bit of a rejection I thought. A recipe for clock inconsitency whatever the failings of the current clock. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ We need a taxonomy for 'printing-that-is-no-longer-printing.' - overhead by WIRED at the Intelligent Printing conference Oct2006 ___ Python-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] Preparation for VS2010 - MSDN for Windows build slaves, core devs
Hi all, If you are a running a build slave or otherwise have an MSDN account for development work, please check that your MSDN subscription is still in effect. If the subscription expired, please let me know in private what your subscriber ID is along with the email address you use for the account. Eventually we're switching to VS2010 so each slave will need to have that version of the compiler installed. Thanks ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
I like the aim of letting the user control what clock it get, but I find this API pretty horrible: clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC) Just my 2 groszy. //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
