Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator
On 6/26/2014 6:59 PM, Ben Hoyt wrote: Rationale = Python's built-in ``os.walk()`` is significantly slower than it needs to be, because -- in addition to calling ``os.listdir()`` on each directory -- it executes the system call ``os.stat()`` or ``GetFileAttributes()`` on each file to determine whether the entry is a directory or not. But the underlying system calls -- ``FindFirstFile`` / ``FindNextFile`` on Windows and ``readdir`` on Linux and OS X -- already tell you whether the files returned are directories or not, so no further system calls are needed. In short, you can reduce the number of system calls from approximately 2N to N, where N is the total number of files and directories in the tree. (And because directory trees are usually much wider than they are deep, it's often much better than this.) One of the major reasons for this seems to be efficiently using information that is already available from the OS "for free". Unfortunately it seems that the current API and most of the leading alternate proposals hide from the user what information is actually there "free" and what is going to incur an extra cost. I would prefer an API that simply gives whatever came for free from the OS and then let the user decide if the extra expense is worth the extra information. Maybe that stat information was only going to be used for an informational log that can be skipped if it's going to incur extra expense? Janzert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
On 7/8/2014 9:52 AM, Ben Hoyt wrote: DirEntry fields being "static" attribute-only objects - In `this July 2014 python-dev message <https://mail.python.org/pipermail/python-dev/2014-July/135303.html>`_, Paul Moore suggested a solution that was a "thin wrapper round the OS feature", where the ``DirEntry`` object had only static attributes: ``name``, ``full_name``, and ``is_X``, with the ``st_X`` attributes only present on Windows. The idea was to use this simpler, lower-level function as a building block for higher-level functions. At first there was general agreement that simplifying in this way was a good thing. However, there were two problems with this approach. First, the assumption is the ``is_dir`` and similar attributes are always present on POSIX, which isn't the case (if ``d_type`` is not present or is ``DT_UNKNOWN``). Second, it's a much harder-to-use API in practice, as even the ``is_dir`` attributes aren't always present on POSIX, and would need to be tested with ``hasattr()`` and then ``os.stat()`` called if they weren't present. Only exposing what the OS provides for free will make the API too difficult to use in the common case. But is there a nice way to expand the API that will allow the user who is trying to avoid extra expense know what information is already available? Even if the initial version doesn't have a way to check what information is there for free, ensuring there is a clean way to add this in the future would be really nice. Janzert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
On 12/31/2013 1:13 PM, Dan Stromberg wrote: On Tue, Dec 31, 2013 at 1:50 AM, Paul Moore wrote: On 31 December 2013 05:31, Dan Stromberg wrote: So far the results are looking good for 3.x. Where can the results be seen? I don't think there's a publicly-available results page yet. I'll summarize them after more people have had a chance to fill it out. I'm trying to get it onto planet python - that should help. But I created the blog post without a Python label initially, and added it afterward - not sure if that'll work or not. I submitted it to hacker news[1] and it has been sitting around #5 on the front page for about 3 hours now. That should've helped broaden the responses a bit. Janzert 1. https://news.ycombinator.com/item?id=6990481 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.x vs 3.x survey results
On 1/2/2014 10:01 PM, Chris Angelico wrote: On Fri, Jan 3, 2014 at 1:18 PM, Dan Stromberg wrote: I don't know much (if anything ^_^) about survey methodology. I just created a 9 question survey and tossed it at a few places that Pythonistas hang out. Specifically, your methodology was to post the link to python-list and python-dev (and whatever else I didn't see). Apart from "hacker news" - not sure if that's a specific site or you're talking generically - your current description sounds right. ChrisA I added links to the actual posts to help clarify where and how it was posted. Janzert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Appeal for reviews
On 4/13/2014 2:36 AM, Stephen J. Turnbull wrote: [snip] My claim is that in current circumstances, core-mentorship would be a more *effective* channel because - core-mentorship is *explicitly* for poking Those Who Can Help (among other requests for help); - a surprisingly large (to me, anyway :-) fraction of core committers and people who may not be "core" but do a lot of mentoring for central projects like IDLE do hang out there; and - when reading core-mentorship their "mentor modes" will be engaged, whereas on python-dev they will often be mostly interested in a particular thread. It saddens me that the core-mentorship list has grown into the primary acceptable place to ask these getting into core development questions. Any question answered there can never benefit the wider community since it is kept a closed list for the specific purpose of keeping its archives out of public view. Janzert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On 4/25/2014 5:52 PM, Carl Meyer wrote: - we aren't talking about real variance from the spirit or recommendations of PEP 8 So the one example under discussion is: foo = long_function_name( var_one, var_two, var_three, var_four) and comes from http://legacy.python.org/dev/peps/pep-0008/#indentation Specifically the third example with a heading of "Optional". From my reading of the text, plus all the other examples around it, I would have assumed the 2 space indent was simply a typo and should have indeed been 4 spaces. If this is really meant to show that indents other than 4 spaces are allowed in this situation maybe verbiage to that effect could be added. Janzert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On 4/27/2014 12:40 PM, Barry Warsaw wrote: On Apr 26, 2014, at 12:33 AM, Janzert wrote: So the one example under discussion is: foo = long_function_name( var_one, var_two, var_three, var_four) and comes from http://legacy.python.org/dev/peps/pep-0008/#indentation Specifically the third example with a heading of "Optional". From my reading of the text, plus all the other examples around it, I would have assumed the 2 space indent was simply a typo and should have indeed been 4 spaces. If this is really meant to show that indents other than 4 spaces are allowed in this situation maybe verbiage to that effect could be added. No, I think it's a typo and should be 4 spaces. I'll fix that. -Barry Given the commits to pep 8 after this, I take it you decided the example really is correct. I'm glad the clarifying sentence got added and comment in the example changed, that should make it clear that the 2 space indent isn't a typo. Janzert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Keyword arguments with non-string names
On 7/9/2019 8:50 AM, Jeroen Demeyer wrote: On 2019-07-09 14:36, Jeroen Demeyer wrote: So this leads to the question: should the interpreter check the keys of a **kwargs dict? Some pointers: - https://bugs.python.org/issue8419 - https://bugs.python.org/issue29360 It was also discussed last October; which I believe is the most recent previous discussion: https://mail.python.org/pipermail/python-dev/2018-October/155435.html Janzert ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JWNYI6K4VNJLBCYG6NHQ6OB7JOOKFWLF/
Re: [Python-Dev] RFC: PEP 454: Add a new tracemalloc module
It seems like most of this could live on PyPi for a while so the API can get hashed out in use? If that's not the case is it because the PEP 445 API isn't rich enough? Janzert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a "transformdict" to collections
On 9/10/2013 10:54 AM, Antoine Pitrou wrote: (also, I would intuitively expect the latest key to be held, not the first one, since that's what happens for values.) Regards Antoine. I intuitively expected, and I think most often would want, the first key to be held. The reason being that I would except most often the initial insertion to be the canonical form. Whichever way is adopted, I think even if you say it's implementation specific, people will end up relying on it in their code. Janzert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/12/2013 6:27 PM, Raymond Hettinger wrote:
On Oct 12, 2013, at 1:41 PM, Ethan Furman mailto:et...@stoneleaf.us>> wrote:
. break_on reads just fine to me, although leave_on is probably better.
Sorry, these are both really bad.
I've user tested ignore() and had good results.
It makes the intention of the code very clear.
I'm curious what your users think this will do
print("start listing")
with ignore(ZeroDivisionError):
for i in range(0, 4):
inv = 1 / i
print("1 over {} is {}".format(i, inv))
print("finished")
I think there's a decent chance I'd get it wrong if I was scanning
through code with that construct in the midst of it.
Janzert
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Why doesn't venv also install python3*-config?
On 1/13/2020 8:21 AM, Daniel Haude wrote: Am 12.01.2020 23:39 schrieb Ivan Pozdeev via Python-Dev: Virtualenv does create `python-config` shim in Linux. Python3 doesn't. Definetely. Not on RHEL7 and Debian, that's where I tested it. Just to ensure there's no confusion; note that "venv" and "virtualenv" are two related but different packages (venv being included in the standard library and virtualenv available on pypi). At least here on Ubuntu 18.04 with python 3.6 venv and virtualenv 16.7.9, venv does not include python-config and virtualenv does. Janzert ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UT4F4JEADTZX5IH5QMZW66A4WJIOS2KV/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Functionality in subprocess.Popen.terminate()
Eric Pruitt wrote: > On Tue, Aug 4, 2009 at 04:27, Nick Coghlan wrote: >> Eric Pruitt wrote: >>> In my GSoC project, I have implemented asnychronous I/O in >>> subprocess.Popen. Since the read/write operations are asynchronous, the >>> program may have already exited by the time one calls the asyncread >>> function I have implemented. While it returns the data just fine, I have >>> come across an issue with the TerminateProcess function in Windows: if >>> the program has already exited, when subprocess.Popen.Terminate calls >>> the Windows built-in "TerminateProcess" function, an "access denied" >>> error will occur. Should I just make it so that this exception is simply >>> ignored or perform some kind of check to see if the process exists >>> beforehand? If the latter, I have been unable to find a way to do so, to >>> my liking at least. The solutions I saw would require code that seems a >>> bit excessive to me. >> I'm pretty sure we already ignore some spurious error messages in cases >> like calling flush() in file.close(). I would suggest checking what the >> io module does in such cases and see what kind of precedent it sets. >> >> Cheers, >> Nick. >> >> -- >> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >> --- >> > > Sounds good enough to me but I was wondering if it might be a good > idea to add a function like "pidinuse" to subprocess as a whole that > would determine if a process ID was being used and return a simple > boolean value. I came across a number of people searching for a way to > determine if a PID was running (Google "python check if pid exists") > so it seems like the implemented functionality would be of use to the > community as a whole, not just my wrapper class. > > Eric > I'm not sure of the actual details but it seems from your description that even if you check first a race condition will still exist. Specifically the subprocess could terminate after the check and before the TerminateProcess call. So it seems better just to call TerminateProcess and then correctly handle any possible error. Janzert ___ 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] unsubscriptable vs object does not support indexing
Steven D'Aprano wrote: > On Thu, 24 Sep 2009 06:47:41 am Dino Viehland wrote: >>> So I am +1 on unified the message and +1 on using the "does not >>> support indexing" one. >> I'd be +1 on the unified message as well - but it seems what that >> message should be may be contentious (and quite a bike shed >> discussion at that). The bug David linked to >> (http://bugs.python.org/issue5760) has a preference for subscript >> because that's what's used elsewhere in the language. > > For what it's worth, "unsubscriptable object" seems to me to be > mysterious to many newbies, and even a few non-newbies. It took me > something like seven years of coding to stop reading it > as "unscriptable object", and I'm sure I won't be the only one. > > As far as I can see, in practice, people talk about obj[i] as the item > at index i, not the item at subscript i -- the term "subscript" in this > context seems to be rare to non-existent except for the error message. > > > How about if it's obj["item"]? To me the following makes complete sense, but then it seems that I may just be the odd one out. >>> class A(object): ... pass ... >>> a = A() >>> a[1] Traceback (most recent call last): File "", line 1, in TypeError: 'A' object is unindexable >>> a["a"] Traceback (most recent call last): File "", line 1, in TypeError: 'A' object is unsubscriptable >>> Janzert ___ 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 3144 review.
Peter Moody wrote:
> On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
>> Peter Moody hda3.com> writes:
>>>>>> def parse_net_and_addr(s):
>>>>>> return (IPNetwork(s), IPAddress(s.split('/')[0]))
>>>>> I've only heard talk of new classes and new methods, not new
>>>>> constructor functions.
>>>> Well, "method" in that context meant "class method" since the results
>>>> aren't
>>>> dependent on a particular instance. Of course, both a class method or a
>>>> module-level function would be fine.
>>> so this is not the response I got when I asked what was required
>>> before. Would adding this constructor function satisfy your concerns
>>> (given sensible strict settings in the constructor, etc)?
>> Assuming the Network type loses the notion of a specific host (or host
>> address,
>> or `ip`) attached to it, yes.
>
> this is "less useful (strictly removing functionality)" and is an
> example of what I explicitly said I was not going to do with ipaddr.
>
> Cheers,
> /peter
>
Not that I should have any say, but I'm also -1 on any proposal that
conflates an "address with mask" and "network" into the same object.
Janzert
___
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] Digital video basics tutorial
http://xiph.org/video/vid1.shtml ___ 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] Digital video basics tutorial
On 10/18/2010 3:33 PM, Janzert wrote: http://xiph.org/video/vid1.shtml Sorry, sent to the wrong place. Janzert ___ 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 365 (Adding the pkg_resources module)
Guido van Rossum wrote: > On Wed, Mar 19, 2008 at 12:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > [a long message] > > I'm back at Google and *really* busy for another week or so, so I'll > have to postpone the rest of this discussion for a while. If other > people want to chime in please do so; if this is just a dialog between > Phillip and me I might incorrectly assume that nobody besides Phillip > really cares. > Since there seems to be a fair number of negative responses to setuptools, I just wanted to add a bit of positive counterbalance. I'm just a random python user that happens to track python-dev a bit, so take all this with the realization that I probably shouldn't have much input into anything. ;) I've been using python for somewhere around 10 years to write various random small scripts, gui applications and recently web applications. For me setuptools is the best thing to happen to python since I've been using it. I develop and deploy on a seemingly constantly changing mix of various flavors of windows and linux. Unlike for others, I love that once I get setuptools installed I can just use the same commands to get the things I need. I guess the contrast for me is that python is the common base that I tend to work from not the underlying OS. So I don't know if I'm part of a large number of quiet users or just happen to be an odd case that works really well with setuptools. I was disappointed when setuptools didn't make it into 2.5 and I really hope it or something very much like it can make it into a release in the near future. Because while setuptools certainly isn't perfect, for me at least, it is much, much better than nothing at all. Brian Haskin ___ 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: Consolidating names and classes in the `unittest`module (updated 2008-07-15)
Raymond Hettinger wrote: ``set_up(…)`` Replaces ``setUp(…)`` . . ``tear_down(…)`` Replaces ``tearDown(…)`` Am I the only one who finds this sort of excessive pep-8 underscoring to be horrorific? Nobody I know spells setup and teardown as two words. I dread using the module with these new names. Underscores are not fun to type. They create a weird_mental_pause when reading them. +1 And Merriam-Webster agrees, http://www.merriam-webster.com/dictionary/setup http://www.merriam-webster.com/dictionary/teardown Janzert ___ 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] Merging mailing lists
Martin v. Löwis wrote: > I would like to merge mailing lists, now that the design and first > implementation of Python 3000 is complete. In particular, I would > like to merge the python-3000 mailing list back into python-dev, > and the python-3000-checkins mailing list back into python-checkins. > The rationale is to simplify usage of the lists, and to avoid > cross-postings. > > To implement this, all subscribers of the 3000 mailing lists would > be added to the trunk mailing lists (avoiding duplicates, of course), > and all automated messages going to python-3000-checkins would then > be directed to the trunk lists. The 3000 mailing lists would change > into read-only mode (i.e. primarily leaving the archives behind). > > Any objections? > > Regards, > Martin I like the general sentiment, but I think it may be a bad idea to automatically bring all the subscribers from the -3000 lists over to the more general lists. For instance if someone has an address subscribed specifically to archive the -3000 list suddenly it will begin archiving the other. I would rather just see a final announcement to switch to the other list and then close the list to further submissions. Let people join the new appropriate list manually if needed. Otherwise +1 on getting the discussion and checkins back into combined lists. Janzert ___ 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] Counting collisions for the win
On 1/23/2012 1:25 PM, Glenn Linderman wrote: On 1/23/2012 12:53 AM, Frank Sievertsen wrote: What if we use a second (randomized) hash-function in case there are many collisions in ONE lookup. This hash-function is used only for collision resolution and is not cached. So this sounds like SafeDict, but putting it under the covers and automatically converting from dict to SafeDict after a collision threshold has been reached. Let's call it fallback-dict. If you're going to essentially switch data structures dynamically anyway, why not just switch to something that doesn't have n**2 worse case performance? Janzert ___ 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 3/23/2012 7:25 PM, Victor Stinner wrote: [snip] - 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. time.steady() is something like: try: return time.monotonic() except (NotImplementError, OSError): return time.time() 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. Janzert ___ 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 3/24/2012 6:37 AM, Victor Stinner wrote: - 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 I can't think of a word or short phrase that adequately describes that behavior, no. But that may just be because I also don't see any use case for it either. To me the more useful function would be one that used the OS monotonic clock when available and failing that used the realtime clock but cached the previous returned value and ensured that all values returned obeyed the monotonic property still. But I don't see why that function shouldn't just be time.monotonic(). Janzert ___ 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 418 is too divisive and confusing and should be postponed
On 4/5/2012 6:32 AM, Victor Stinner wrote: Since the only monotonic clock that can be adjusted by NTP is Linux' CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always give a clock that isn't adjusted by NTP. I thought we decided that NTP adjustment isn't an issue, because it's always gradual. Well, in timings it is an issue, but perhaps not a big one. :-) In any case, which one we use will not change the API, so if it is decided it is an issue, we can always more to CLOCK_MONOTONIC_RAW in the future, once Linux< 2.6.26 (or whatever it was) is deemed unsupported. I prefer to use CLOCK_MONOTONIC, not because it is also available for older Linux kernels, but because it is more reliable. Even if the underlying clock source is unstable (unstable frequency), a delta of two reads of the CLOCK_MONOTONIC clock is a result in *seconds*, whereas CLOCK_MONOTONIC_RAW may use an unit a little bit bigger or smaller than a second. time.monotonic() unit is the second, as written in its documentation. I believe the above is only true for sufficiently large time deltas. One of the major purposes of NTP slewing is to give up some short term accuracy in order to achieve long term accuracy (e.g. whenever the clock is found to be ahead of real time it is purposefully ticked slower than real time). So for benchmarking it would not be surprising to be better off with the non-adjusted clock. Ideally there would be a clock that was slewed "just enough" to try and achieve short term accuracy, but I don't know of anything providing that. Janzert ___ 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 418 is too divisive and confusing and should be postponed
On 4/7/2012 5:49 AM, Victor Stinner wrote: 2012/4/7 Janzert: On 4/5/2012 6:32 AM, Victor Stinner wrote: I prefer to use CLOCK_MONOTONIC, not because it is also available for older Linux kernels, but because it is more reliable. Even if the underlying clock source is unstable (unstable frequency), a delta of two reads of the CLOCK_MONOTONIC clock is a result in *seconds*, whereas CLOCK_MONOTONIC_RAW may use an unit a little bit bigger or smaller than a second. time.monotonic() unit is the second, as written in its documentation. I believe the above is only true for sufficiently large time deltas. One of the major purposes of NTP slewing is to give up some short term accuracy in order to achieve long term accuracy (e.g. whenever the clock is found to be ahead of real time it is purposefully ticked slower than real time). I don't think that NTP works like that. NTP only uses very smooth adjustements: ""slewing": change the clock frequency to be slightly faster or slower (which is done with adjtime()). Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize." http://www.python.org/dev/peps/pep-0418/#ntp-adjustment Right, the description in that paragraph is exactly what I was referring to above. :) It is unfortunate that a clock with a resolution of 1ns may be purposefully thrown off by 500,000ns per second in the short term. In practice you are probably correct that it is better to take the slewed clock even though it may have purposeful short term inaccuracy thrown in than it is to use the completely unadjusted one. So for benchmarking it would not be surprising to be better off with the non-adjusted clock. Ideally there would be a clock that was slewed "just enough" to try and achieve short term accuracy, but I don't know of anything providing that. time.monotonic() is not written for benchmarks. It does not have the highest frequecency, it's primary property is that is monotonic. A side effect is that it is usually the steadiest clock. For example, on Windows time.monotonic() has only an accuracy of 15 ms (15 milliseconds not 15 microseconds). Hmm, I just realized an unfortunate result of that. Since it means time.monotonic() will be too coarse to be useful for frame rate level timing on windows. Janzert ___ 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] Draft PEP for time zone support.
On 12/12/2012 8:43 PM, Glenn Linderman wrote: On 12/12/2012 5:36 PM, Brian Curtin wrote: >> C:\ProgramData\Python ^ That. Is not the path that the link below is talking about, though. It actually does; it is rather confusing though. :/ It's referring to KNOWNFOLDERID constant FOLDERID_ProgramData. The actual on disk location for this has changed over windows versions. As noted below in the SO link given: "Note that this documentation refers to the typical path as per older versions of Windows. In modern versions of Windows it is located in %SystemDrive%\ProgramData." > > > Making a new top-level directory without asking is obnoxious. See http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows ___ 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] Draft PEP for time zone support.
On 12/13/2012 1:39 AM, Glenn Linderman wrote: On 12/12/2012 6:10 PM, Janzert wrote: On 12/12/2012 8:43 PM, Glenn Linderman wrote: On 12/12/2012 5:36 PM, Brian Curtin wrote: >> C:\ProgramData\Python ^ That. Is not the path that the link below is talking about, though. It actually does; it is rather confusing though. :/ I agree with the below. But I have never seen a version of Windows on which c:\ProgramData was the actual path for FOLDERID_ProgramData. Can you reference documentation that states that it was there, for some version? This documentation speaks of: c:\Documents and Settings\AllUsers\Application Data (which I knew from XP, and I think 2000, not sure I remember NT) In Vista.0, Vista.1, and Vista.2, I guess it is moved to C:\users\AllUsers\AppData\Roaming (typically). Neither of those would result in C:\ProgramData\Python. The SO answer links to the KNOWNFOLDERID docs; the relevant entry specifically is at http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457.aspx#FOLDERID_ProgramData which gives the default path as, %ALLUSERSPROFILE% (%ProgramData%, %SystemDrive%\ProgramData) checking on my local windows 7 install gives: C:\>echo %ALLUSERSPROFILE% C:\ProgramData C:\>echo %ProgramData% C:\ProgramData It's referring to KNOWNFOLDERID constant FOLDERID_ProgramData. The actual on disk location for this has changed over windows versions. As noted below in the SO link given: "Note that this documentation refers to the typical path as per older versions of Windows. In modern versions of Windows it is located in %SystemDrive%\ProgramData." > > > Making a new top-level directory without asking is obnoxious. See http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows ___ 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
