Re: [Python-Dev] This isn't a question

On 11 November 2015 at 04:09, Brett Cannon wrote: > You're quite welcome! And thanks for taking the time to say "thanks". :) Indeed! Folks saying "Thank you" has a surprisingly big impact, since our natural tendency is to spend time dwelling on all the things that still need improvement :) Regar

Re: [Python-Dev] This isn't a question

While I'm a part of the community, that wasn't always the case and it's very large, so I'll take this opportunity to come in and say a big thank you as well! From: br...@python.org Date: Tue, 10 Nov 2015 18:09:37 + To: a.r.ka...@gmail.com; python-dev@python.org Subject: R

Re: [Python-Dev] This isn't a question

You're quite welcome! And thanks for taking the time to say "thanks". :) On Tue, 10 Nov 2015, 11:35 Alec Kaija wrote: > Sorry to bother anyone, but I just wanted to thank the Python community > for being awesome and for all of the ways you have all inspired/supported > me (mostly without even kn

[Python-Dev] This isn't a question

Sorry to bother anyone, but I just wanted to thank the Python community for being awesome and for all of the ways you have all inspired/supported me (mostly without even knowing it). Thanks! a ___ Python-Dev mailing list Python-Dev@python.org https://m

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Fri Apr 18 2014 at 5:03:33 PM, Ezio Melotti wrote: > Hi, > > On Thu, Apr 17, 2014 at 9:09 PM, Brett Cannon wrote: > > > > > > On Thu Apr 17 2014 at 1:34:23 PM, Jurko Gospodnetić > > wrote: > >> > >>Hi. > >> > >> On 14.4.2014. 23:51, Brett Cannon wrote: > >> > Now the question is whether

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 18.04.2014 23:03, Ezio Melotti wrote: > Hi, > > On Thu, Apr 17, 2014 at 9:09 PM, Brett Cannon wrote: >> >> >> On Thu Apr 17 2014 at 1:34:23 PM, Jurko Gospodnetić >> wrote: >>> >>>Hi. >>> >>> On 14.4.2014. 23:51, Brett Cannon wrote: Now the question is whether the maintenance cost of

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Hi, On Thu, Apr 17, 2014 at 9:09 PM, Brett Cannon wrote: > > > On Thu Apr 17 2014 at 1:34:23 PM, Jurko Gospodnetić > wrote: >> >>Hi. >> >> On 14.4.2014. 23:51, Brett Cannon wrote: >> > Now the question is whether the maintenance cost of having to rebuild >> > Python for a select number of st

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/2014 06:06 PM, Brett Cannon wrote: > On Thu Apr 17 2014 at 5:21:14 PM, "Martin v. Löwis" > wrote: > >> Am 17.04.14 20:47, schrieb Brett Cannon: >>> Because people keep bringing it up, below is the results of >>> hacking up the interpreter to

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Thu Apr 17 2014 at 5:21:14 PM, "Martin v. Löwis" wrote: > Am 17.04.14 20:47, schrieb Brett Cannon: > > Because people keep bringing it up, below is the results of hacking up > > the interpreter to include a sys.path entry for ./python35.zip instead > > of hard-coding to /usr/lib/python35.zip a

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Am 17.04.14 20:47, schrieb Brett Cannon: > Because people keep bringing it up, below is the results of hacking up > the interpreter to include a sys.path entry for ./python35.zip instead > of hard-coding to /usr/lib/python35.zip and simply zipped up Lib/ > recursively. TL;DR, zipimport performance

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Am 17.04.14 20:47, schrieb Brett Cannon: > Because people keep bringing it up, below is the results of hacking up > the interpreter to include a sys.path entry for ./python35.zip instead > of hard-coding to /usr/lib/python35.zip and simply zipped up Lib/ > recursively. TL;DR, zipimport performance

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Thu, Apr 17, 2014 at 1:31 PM, Brett Cannon wrote: > > On Thu Apr 17 2014 at 3:21:49 PM, Guido van Rossum > wrote: > >> I'm sorry to keep asking dumb questions, but your description didn't job >> my understanding of what you are comparing here. What is slower than what? >> > > Startup where t

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Thu Apr 17 2014 at 3:21:49 PM, Guido van Rossum wrote: > I'm sorry to keep asking dumb questions, but your description didn't job > my understanding of what you are comparing here. What is slower than what? > Startup where the stdlib is entirely in a zip file is slower than the status quo of

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Apr 17, 2014, at 2:23 PM, Jurko Gospodnetić wrote: > Hi. > > On 17.4.2014. 19:57, Guido van Rossum wrote: >> On Thu, Apr 17, 2014 at 10:33 AM, Jurko Gospodnetić >> mailto:jurko.gospodne...@pke.hr>> wrote: >> >> I would really love to have better startup times in production, >> >> Wh

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

I'm sorry to keep asking dumb questions, but your description didn't job my understanding of what you are comparing here. What is slower than what? On Thu, Apr 17, 2014 at 11:47 AM, Brett Cannon wrote: > Because people keep bringing it up, below is the results of hacking up the > interpreter to

[Python-Dev] this is what happens if you freeze all the modules required for startup

On Thu Apr 17 2014 at 3:10:46 PM, Brett Cannon wrote: > Actually ignore this data, I think I may have messed something up. I'll > reply after I check something > Unfortunately my check says the data is accurate, so zip startup is really just slow. -Brett > > On Thu Apr 17 2014 at 2:47:52 PM,

[Python-Dev] this is what happens if you freeze all the modules required for startup

Actually ignore this data, I think I may have messed something up. I'll reply after I check something On Thu Apr 17 2014 at 2:47:52 PM, Brett Cannon wrote: > Because people keep bringing it up, below is the results of hacking up the > interpreter to include a sys.path entry for ./python35.zip in

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Hi. On 17.4.2014. 19:57, Guido van Rossum wrote: On Thu, Apr 17, 2014 at 10:33 AM, Jurko Gospodnetić mailto:jurko.gospodne...@pke.hr>> wrote: I would really love to have better startup times in production, What's your use case? I understand why startup time is important for Hg, but I'

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Thu, Apr 17, 2014 at 8:17 PM, Antoine Pitrou wrote: > On Thu, 17 Apr 2014 18:09:22 + > Brett Cannon wrote: > > > > > >I would really love to have better startup times in production, but > I > > > would also really hate to lose the ability to hack around in stdlib > > > sources during

[Python-Dev] this is what happens if you freeze all the modules required for startup

Because people keep bringing it up, below is the results of hacking up the interpreter to include a sys.path entry for ./python35.zip instead of hard-coding to /usr/lib/python35.zip and simply zipped up Lib/ recursively. TL;DR, zipimport performance no longer measures up (probably because of stat c

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 04/17/2014 10:33 AM, Jurko Gospodnetić wrote: In general, what I really like about using Python for software development is the ability to open any stdlib file and easily go poking around using stuff like 'import pdb;pdb.set_trace()' or simple print statements. +1 -- ~Ethan~ _

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Hi. On 17.4.2014. 20:15, Mark Young wrote: I think he meant modifying the source files themselves for debugging purposes (e.g. putting print statements in itertools.py). Exactly! :-) Best regards, Jurko Gospodnetić ___ Python-Dev mailing

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

I still do that! On Thu, Apr 17, 2014 at 11:17 AM, Antoine Pitrou wrote: > On Thu, 17 Apr 2014 18:09:22 + > Brett Cannon wrote: > > > > > >I would really love to have better startup times in production, but > I > > > would also really hate to lose the ability to hack around in stdlib >

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Thu, 17 Apr 2014 18:09:22 + Brett Cannon wrote: > > > >I would really love to have better startup times in production, but I > > would also really hate to lose the ability to hack around in stdlib > > sources during development just to get better startup performance. > > > >In gener

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

I think he meant modifying the source files themselves for debugging purposes (e.g. putting print statements in itertools.py). 2014-04-17 14:09 GMT-04:00 Brett Cannon : > > > On Thu Apr 17 2014 at 1:34:23 PM, Jurko Gospodnetić < > jurko.gospodne...@pke.hr> wrote: > >>Hi. >> >> On 14.4.2014.

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Thu Apr 17 2014 at 1:34:23 PM, Jurko Gospodnetić < jurko.gospodne...@pke.hr> wrote: >Hi. > > On 14.4.2014. 23:51, Brett Cannon wrote: > > Now the question is whether the maintenance cost of having to rebuild > > Python for a select number of stdlib modules is enough to warrant > > putting i

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Thu, Apr 17, 2014 at 10:33 AM, Jurko Gospodnetić < jurko.gospodne...@pke.hr> wrote: > I would really love to have better startup times in production, What's your use case? I understand why startup time is important for Hg, but I'd like to understand what other situations occur frequently en

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Hi. On 14.4.2014. 23:51, Brett Cannon wrote: Now the question is whether the maintenance cost of having to rebuild Python for a select number of stdlib modules is enough to warrant putting in the effort to make this work. I would really love to have better startup times in production, but

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Wed Apr 16 2014 at 4:53:25 PM, Terry Reedy wrote: > > On Wednesday, April 16, 2014 2:57:35 PM, Terry Reedy > > wrote: > > > PS. In the user process sys.modules, there are numerous null > > entries like these: > > >>> sys.modules['idlelib.os'] > >

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

> On Wednesday, April 16, 2014 2:57:35 PM, Terry Reedy > wrote: > PS. In the user process sys.modules, there are numerous null > entries like these: > >>> sys.modules['idlelib.os'] > >>> sys.modules['idlelib.tokenize'__] > >>> sys.modules['idlel

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 16 April 2014 12:25, "Martin v. Löwis" wrote: > Am 14.04.14 23:51, schrieb Brett Cannon: >> It was realized during PyCon that since we are freezing importlib we >> could now consider freezing all the modules to cut out having to stat or >> read them from disk. > [...] >> Thoughts? > > They stil

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Is this Python 2 or 3? In Python 2 it means an attempt to perform a relative import failed but an absolute in succeeded, e.g. from idlelib you imported os, so import tried idlelib.is and then os. You should definitely consider using a future import to guarantee absolute imports. On Wednesday, Apri

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 4/16/2014 12:25 PM, "Martin v. Löwis" wrote: Am 14.04.14 23:51, schrieb Brett Cannon: It was realized during PyCon that since we are freezing importlib we could now consider freezing all the modules to cut out having to stat or read them from disk. [...] Thoughts? They still get read from

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Am 14.04.14 23:51, schrieb Brett Cannon: > It was realized during PyCon that since we are freezing importlib we > could now consider freezing all the modules to cut out having to stat or > read them from disk. [...] > Thoughts? They still get read from disk, except that it is the operating system

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Brett Cannon, 14.04.2014 23:51: > It was realized during PyCon that since we are freezing importlib we could > now consider freezing all the modules to cut out having to stat or read > them from disk. So for day 1 of the sprints I I decided to hack up a > proof-of-concept to see what kind of perfor

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Wed, Apr 16, 2014 at 4:54 AM, Guido van Rossum wrote: > Can we please stop the argument about Hg vs. Git? My apologies. All I was saying was that hg is a use case where startup performance really does matter, as opposed to the ones presented earlier in the thread where a process stays in memor

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Can we please stop the argument about Hg vs. Git? On Tue, Apr 15, 2014 at 12:54 PM, Chris Angelico wrote: > On Wed, Apr 16, 2014 at 2:40 AM, Antoine Pitrou > wrote: > > Le 15/04/2014 09:45, Chris Angelico a écrit : > > > >> > >> Specific use-case that I can see: Mercurial. In a git vs hg shoot

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Wed, Apr 16, 2014 at 2:40 AM, Antoine Pitrou wrote: > Le 15/04/2014 09:45, Chris Angelico a écrit : > >> >> Specific use-case that I can see: Mercurial. In a git vs hg shoot-out, >> git will usually win on performance, and hg is using Py2; > > > Keep in mind those shoot-outs usually rely on lar

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Le 14/04/2014 23:51, Brett Cannon a écrit : It was realized during PyCon that since we are freezing importlib we could now consider freezing all the modules to cut out having to stat or read them from disk. So for day 1 of the sprints I I decided to hack up a proof-of-concept to see what kind of

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

Le 15/04/2014 09:45, Chris Angelico a écrit : Specific use-case that I can see: Mercurial. In a git vs hg shoot-out, git will usually win on performance, and hg is using Py2; Keep in mind those shoot-outs usually rely on large repositories and/or non-trivial operations, so startup time is not

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Tue, Apr 15, 2014 at 11:19 AM, Daniel Holth wrote: > IIRC it is no longer the case that ZIP imports (involving only one > file for a lot of modules) are much faster than regular FS imports? > It's definitely minimized since Python 3.3 and the caching of stat results at the directory level for

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

IIRC it is no longer the case that ZIP imports (involving only one file for a lot of modules) are much faster than regular FS imports? On Tue, Apr 15, 2014 at 10:34 AM, Eric Snow wrote: > On Tue, Apr 15, 2014 at 1:45 AM, Chris Angelico wrote: >> Specific use-case that I can see: Mercurial. In a

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Tue, Apr 15, 2014 at 1:45 AM, Chris Angelico wrote: > Specific use-case that I can see: Mercurial. In a git vs hg shoot-out, > git will usually win on performance, and hg is using Py2; migrating hg > to Py3 will (if I understand the above figures correctly) widen that > gap, so any improvement

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Mon, Apr 14, 2014 at 3:51 PM, Brett Cannon wrote: > It was realized during PyCon that since we are freezing importlib we could > now consider freezing all the modules to cut out having to stat or read them > from disk. So for day 1 of the sprints I I decided to hack up a > proof-of-concept to s

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 15.04.2014 09:45, Chris Angelico wrote: > On Tue, Apr 15, 2014 at 8:21 AM, Brett Cannon wrote: >>> In my work environment (Python 2.7.2, all the heavy lifting done in >>> C++), startup costs are dominated by dynamic linking of all our C++ >>> libraries and their Boost wrappers: >> >> >> Sure, b

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 14 Apr 2014 18:37, "Glenn Linderman" wrote: > > On 4/14/2014 2:51 PM, Brett Cannon wrote: >> >> Freezing everything except encodings.__init__, os, and _sysconfigdata, > > > I suppose these are omitted because they can vary in different environments? > > But isn't Python built for a particular e

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Tue, Apr 15, 2014 at 8:21 AM, Brett Cannon wrote: >> In my work environment (Python 2.7.2, all the heavy lifting done in >> C++), startup costs are dominated by dynamic linking of all our C++ >> libraries and their Boost wrappers: > > > Sure, but not everyone uses Boost or has long running proc

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 4/14/2014 2:51 PM, Brett Cannon wrote: Freezing everything except encodings.__init__, os, and _sysconfigdata, I suppose these are omitted because they can vary in different environments? But isn't Python built for a particular environment... seems like os could be included? Seems like it

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Mon, Apr 14, 2014 at 6:07 PM, Glenn Linderman wrote: > On 4/14/2014 2:51 PM, Brett Cannon wrote: > > consider freezing all the modules > > ... > > Now the question is whether the maintenance cost of having to rebuild > Python for a select number of stdlib modules > > > "all" versus "select n

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Mon, Apr 14, 2014 at 6:15 PM, Skip Montanaro wrote: > On Mon, Apr 14, 2014 at 4:51 PM, Brett Cannon wrote: > > Thoughts? > > Interesting idea, but YAGNI? > Not at all. Think of every script you execute that's written in Python. One of the things the Mercurial folks say is hindering any motiv

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Mon, Apr 14, 2014 at 4:51 PM, Brett Cannon wrote: > Thoughts? Interesting idea, but YAGNI? In my work environment (Python 2.7.2, all the heavy lifting done in C++), startup costs are dominated by dynamic linking of all our C++ libraries and their Boost wrappers: % time python -c 'import trad

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 4/14/2014 2:51 PM, Brett Cannon wrote: consider freezing all the modules ... Now the question is whether the maintenance cost of having to rebuild Python for a select number of stdlib modules "all" versus "select number". So I'm guessing the proposal is to freeze all the modules that Pyth

[Python-Dev] this is what happens if you freeze all the modules required for startup

It was realized during PyCon that since we are freezing importlib we could now consider freezing all the modules to cut out having to stat or read them from disk. So for day 1 of the sprints I I decided to hack up a proof-of-concept to see what kind of performance gain it would get. Freezing every

Re: [Python-Dev] this python string literals documentation couldn't explain me: single quote presence inside double quoted string and viceversa. Can Anyone explain me?

Thanks for you answer sir, I was thinking its regular expressions(automata) not BNF grammer. Aint I right ? And I thought even if it is for human reading, if we write literal grammer ( regular expression, in my view) using documentation, we would end up with python not allowing strings like"python

Re: [Python-Dev] this python string literals documentation couldn't explain me: single quote presence inside double quoted string and viceversa. Can Anyone explain me?

On 08/05/13 21:31, Alok Nayak wrote: I asked this question here, http://stackoverflow.com/questions/16435233/this-python-string-literals-documentation-couldnt-explain-me-single-quote-pres, . I was advised to ask here They were wrong. It is not relevant here, since it is not a question about d

[Python-Dev] this python string literals documentation couldn't explain me: single quote presence inside double quoted string and viceversa. Can Anyone explain me?

This python string literals documentationcouldn't explain: single quote presence inside double quoted string and viceversa. I think both double quoted string and single quoted string need to be defined differently for repr

Re: [Python-Dev] this python string literals documentation couldn't explain me: single quote presence inside double quoted string and viceversa. Can Anyone explain me?

I asked this question here, http://stackoverflow.com/questions/16435233/this-python-string-literals-documentation-couldnt-explain-me-single-quote-pres, . I was advised to ask here On Wed, May 8, 2013 at 4:56 PM, Alok Nayak wrote: > > This python string literals > documentation

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

>> We're going around in circles. I'm not asking what sleep does, I want >> on principle a timer that does the same thing as sleep(), regardless >> of how sleep() works. So if on some OS sleep() uses the same algorithm >> as CLOCK_MONOTONIC_RAW, I want my timer to use that too. But if on >> some ot

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

>> sleep() is implemented in the kernel. The kernel is notified when a >> clock is set, and so can choose how to handle time adjustement. Most >> "sleeping" functions use the system clock but don't care of clock >> adjustement. > > We're going around in circles. I'm not asking what sleep does, I wa

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On 09Apr2012 13:26, Victor Stinner wrote: | > | On Windows, GetProcessTimes() has not a "high-resolution": it has a | > | accuracy of 1 ms in the best case. | > | > This page: | >   http://msdn.microsoft.com/en-us/library/windows/desktop/ms683223%28v=vs.85%29.aspx | > says "100-nanosecond time uni

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

> |  * time.process_time(): High-resolution (?) per-process timer from the > | CPU. (other possible names: time.process_cpu_time() or > | time.cpu_time()) > > POSIX offers CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID that > seem to suit this need, depending on your threading situation (and

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

2012/4/9 Guido van Rossum : >>You may need two clocks >> for this: >>  * time.perf_counter(): high-resolution timer for benchmarking, count >> time elasped during a sleep >>  * time.process_time(): High-resolution (?) per-process timer from the >> CPU. (other possible names: time.process_cpu_time()

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Sun, Apr 8, 2012 at 5:00 PM, Victor Stinner wrote: >> IOW "What's good enough for sleep() is good enough for >> user-implemented timeouts and scheduling." as a way to reach at least >> one decision for a platform with agreed-upon cross-platform >> characteristics that are useful. > > sleep() is

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On 09Apr2012 02:00, Victor Stinner wrote: | > I personally have a need for one potentially different clock -- to | > measure short intervals for benchmarks and profiling. This might be | > called time.performancetimer()? | | I deferred this topic because it is unclear to me if such timer has to |

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

> IOW "What's good enough for sleep() is good enough for > user-implemented timeouts and scheduling." as a way to reach at least > one decision for a platform with agreed-upon cross-platform > characteristics that are useful. sleep() is implemented in the kernel. The kernel is notified when a cloc

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Sun, 8 Apr 2012 07:29:30 -0700 Guido van Rossum wrote: > > What to name it can't be decided this way, although I might put > forward time.sleeptimer(). interval_timer() ? I would suggest timer() simply, but it's too close to time(). > I personally have a need for one potentially different cl

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Sun, Apr 8, 2012 at 3:42 AM, Antoine Pitrou wrote: > >> | I made the same suggestion earlier but I don't know that anyone did >> | anything with it. :-( It would be nice to know what clock sleep() uses >> | on each of the major platforms. >> >> I saw it but didn't know what I could do with it,

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

> | I made the same suggestion earlier but I don't know that anyone did > | anything with it. :-( It would be nice to know what clock sleep() uses > | on each of the major platforms. > > I saw it but didn't know what I could do with it, or even if it can be > found out in any very general sense.

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On 07Apr2012 18:49, Guido van Rossum wrote: | On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger | wrote: | > Just to clarify my previous post. | > It seems clear that benchmarking and timeout logic would benefit | > from a clock that cannot be adjusted by NTP. Indeed. Except for calendar program

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger wrote: > Just to clarify my previous post. > > It seems clear that benchmarking and timeout logic would benefit from a clock > that cannot be adjusted by NTP. > > I'm unclear on whether time.sleep() will be based on the same clock so that > timeo

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Victor et al, Just an update note: I've started marking up clocks with attributes; not yet complete and I still need to make a small C extension to present the system clocks to Python space (which means learning to do that, too). But you can glance over the start on it here: https://bitbucket

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Just to clarify my previous post. It seems clear that benchmarking and timeout logic would benefit from a clock that cannot be adjusted by NTP. I'm unclear on whether time.sleep() will be based on the same clock so that timeouts and sleeps are on the same basis. For scheduling logic (such as t

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Frá: python-dev-bounces+kristjan=ccpgames@python.org [python-dev-bounces+kristjan=ccpgames@python.org] fyrir hönd Guido van Rossum [gu...@python.org] Sent: 6. apríl 2012 15:42 To: Paul Moore Cc: Python-Dev Efni: Re: [Python-Dev] this is why we shouldn't call

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Apr 7, 2012, at 3:08 AM, Paul Moore wrote: > Use cases: > > Display the current time to a human (e.g. display a calendar or draw a > wall clock): use system clock, i.e. time.time() or > datetime.datetime.now(). > Event scheduler, timeout: time.monotonic(). > Benchmark, profiling: time.clock()

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On 07Apr2012 01:47, Victor Stinner wrote: | I don't understand this definition. All clocks have a clock drift. | This is just one exception: atomic clocks, but such clocks are rare | and very expensive. They've got drift too. It is generally very small. Anecdote: I used to keep my wristwatch (oh

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On 7 April 2012 09:12, Stephen J. Turnbull wrote: > > I don't think that's a reason that should be considered.  There just > doesn't seem to be a single best clock, nor do clocks of similar > character seem to be easy to find across platforms.  So the reasons > I'd like to see are of the form "we

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Sat, Apr 7, 2012 at 8:47 AM, Victor Stinner wrote: > "Objects of class steady_clock represent clocks for which values of > time_point advance at a steady rate relative to real time. That is, > the clock may not be adjusted." > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Fri, Apr 6, 2012 at 11:32 PM, Victor Stinner wrote: > On Linux, I now prefer > to use CLOCK_MONOTONIC (monotonic) than CLOCK_MONOTONIC_RAW > (monotonic and steady as defined by C++) *because* its frequency is > adjusted. I don't think that's a reason that should be considered. There just doe

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

> 2. Those who think that "monotonic clock" means a clock that never > jumps, and that runs at a rate approximating the rate of real time. > This is a very useful kind of clock to have! It is what C++ now calls > a "steady clock". It is what all the major operating systems provide. For the "C++" p

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

> | This is the original reason for the original defect (issue 10278) > | unix' clock() doesn't actually provide a clock in this sense, it provides a > resource usage metric. > > Yeah:-( Its help says "Return the CPU time or real time since [...]". > Two very different things, as demonstrated. I s

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On 06Apr2012 17:07, Kristj�n Valur J�nsson wrote: | Steven D'Aprano: | > I think that this is incorrect. | > py> time.clock(); time.sleep(10); time.clock() | > 0.41 | > 0.41 | | This is the original reason for the original defect (issue 10278) | unix' clock() doesn't actually provide a clock in th

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On 06Apr2012 15:19, I wrote: | On 06Apr2012 14:31, Steven D'Aprano wrote: | | Here is a non-monotonic sequence: | | | | 1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8 | | | | This isn't steady either, because it jumps backwards. | | | | To be steady, it MUST also be monotonic. If you think that it is

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

s+kristjan=ccpgames@python.org] fyrir hönd Steven D'Aprano [st...@pearwood.info] Sent: 6. apríl 2012 10:12 To: Python-Dev Efni: Re: [Python-Dev] this is why we shouldn't call it a "monotonicclock" (was: PEP 418 is too divisive and confusing and should be postponed)

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

ictor.stin...@gmail.com] Sent: 6. apríl 2012 14:32 To: Zooko Wilcox-O'Hearn Cc: Python-Dev Efni: Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) The C++ Timeout Specification uses the following

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

I'd like to veto wall clock because to me that's the clock on my wall, i.e. local time. Otherwise I like the way this thread is going. --Guido van Rossum (sent from Android phone) On Apr 6, 2012 4:57 AM, "Paul Moore" wrote: > On 6 April 2012 11:12, Steven D'Aprano wrote: > >> Glyph Lefkowitz wr

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

> 2. Those who think that "monotonic clock" means a clock that never > jumps, and that runs at a rate approximating the rate of real time. > This is a very useful kind of clock to have! It is what C++ now calls > a "steady clock". It is what all the major operating systems provide. Python cannot g

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On 6 April 2012 11:12, Steven D'Aprano wrote: > Glyph Lefkowitz wrote: > >> On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote: >> > > 2. Those who think that "monotonic clock" means a clock that never jumps, >>> and that runs at a rate approximating the rate of real time. This is a >>> very

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Glyph Lefkowitz wrote: On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote: 2. Those who think that "monotonic clock" means a clock that never jumps, and that runs at a rate approximating the rate of real time. This is a very useful kind of clock to have! It is what C++ now calls a "steady

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Fri, Apr 6, 2012 at 3:39 PM, Glyph Lefkowitz wrote: > There seems to be a persistent desire in this discussion to specify and > define these flaws out of existence, where this API really should instead be > embracing the flaws and classifying them. That seems to be precisely what Cameron is a

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote: > On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing > wrote: >> >> This is the strict mathematical meaning of the word "monotonic", but the way >> it's used in relation to OS clocks, it seems to mean rather more than that. > > Yep. As far as I

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On 06Apr2012 14:31, Steven D'Aprano wrote: | Cameron Simpson wrote: | > | The main reason to use the word "monotonic clock" to refer to the | > | second concept is that POSIX does so, but since Mac OS X, Solaris, | > | Windows, and C++ have all avoided following POSIX's mistake, I think | > | Pyth

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Cameron Simpson wrote: | The main reason to use the word "monotonic clock" to refer to the | second concept is that POSIX does so, but since Mac OS X, Solaris, | Windows, and C++ have all avoided following POSIX's mistake, I think | Python should too. No. If it is not monotonic, DO NOT CALL IT

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On 05Apr2012 21:07, Zooko Wilcox-O'Hearn wrote: | On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing wrote: | > This is the strict mathematical meaning of the word "monotonic", | > but the way it's used in relation to OS clocks, it seems to mean rather | > more than that. | | Yep. As far as I can tell,

[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing wrote: > > This is the strict mathematical meaning of the word "monotonic", but the way > it's used in relation to OS clocks, it seems to mean rather more than that. Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock. There se

Re: [Python-Dev] This seems like a bug - main thread has None ident???

skip> Am I missing something obvious or have I hit a bug? This is a skip> fully updated 2.7a0 build, trunk:70878M. After noting that thread.get_ident() returned a thread id but that threading.currentThread().ident was None I concluded that it is, in fact, a bug in the threading module.

[Python-Dev] This seems like a bug - main thread has None ident???

Looking for some quick feedback on this. I've bumped into what looks like a bug in the threading module. From the interpreter prompt: >>> import threading >>> threading.currentThread() <_MainThread(MainThread, started)> >>> print threading.currentThread().ident None The iden

Re: [Python-Dev] This

2006/5/26, Terry Reedy <[EMAIL PROTECTED]>: > And the line before, while not formal English of the kind needed, say, for > Decimal docs, works well enough for me as an expression of an informal > conversational thought. That's why Decimal docs were written by Raymond, ;) -- .Facundo Blog:

Re: [Python-Dev] This

"Facundo Batista" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Just end user experience's two cents here > (btw, this line is correct at English level?) Since you asked...your question would be better written "is this line correct English?" And the line before, while not form

Re: [Python-Dev] This

2006/5/25, Raymond Hettinger <[EMAIL PROTECTED]>: > IIRC, Guido's words were that too much to the smarts in timeit.py were > in the command-line interface and not in the Timer object were in should > be. Just end user experience's two cents here (btw, this line is correct at English level?) I fo

Re: [Python-Dev] This

Steve Holden wrote: > > This reminds me I am tasked with trying to find out what the interface > to timeit.py is supposed to look like. Raymond, your name has been > mentioned as someone who took part int he discussions. Google hasn't > given me a lot to go on. Anyone? > IIRC, Guido's words we

  1   2   >