Re: [Python-Dev] PEP-419: Protecting cleanup statements from interruptions
Hi Benjamin, On Mon, Apr 9, 2012 at 12:42 AM, Benjamin Peterson wrote: > 2012/4/8 Paul Colomiets : >> Function 'sys.setcleanuphook' >> - >> >> A new function for the ``sys`` module is proposed. This function sets >> a callback which is executed every time ``f_in_cleanup`` becomes >> false. Callbacks get a frame object as their sole argument, so that >> they can figure out where they are called from. > > Calling a function every time you leave a finally block? Isn't that a > bit expensive? > For signal handler it isn't, because you set it only when signal happens, and remove it when it first happens (in the common case) For yield-based coroutines, there is a similar overhead of trampoline at each yield and each return, and exit from finally doesn't happen more often than return. For both greenlets and yield-based coroutines it is intented to be used for exceptional situation (when timeout happens *and* coroutine currently in finally block), so can be turned off when unneeded (and even turned on only for this specific coroutine). When hook is not set it's only checking of single pointer for NULL value at each exit from finally. This overhead should be negligible. -- Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Removing surplus fields from the frame object and not adding any new ones.
The frame object is a key object in CPython. It holds the state of a function invocation. Frame objects are allocated, initialised and deallocated at a rapid rate. Each extra field in the frame object requires extra work for each and every function invocation. Fewer fields in the frame object means less overhead for function calls, and cleaner simpler code. We have recently removed the f_yieldfrom field from the frame object. (http://bugs.python.org/issue14230) The f_exc_type, f->f_exc_value, f->f_exc_traceback fields which handle sys.exc_info() in generators could be moved to the generator object. (http://bugs.python.org/issue13897) The f_tstate field is redundant and, it would seem, dangerous (http://bugs.python.org/issue14432) The f_builtins, f_globals, f_locals fields could be combined into a single f_namespaces struct. (http://code.activestate.com/lists/python-dev/113381/) Now PEP 419 proposes adding (yet) another field to the frame object. Please don't. Clean, concise data structures lead to clean, concise code. which we all know is a "good thing" :) Cheers, Mark. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing surplus fields from the frame object and not adding any new ones.
Do you want to create `frame` and `f_namespaces` every function call instead of single `frame` creation? On Mon, Apr 9, 2012 at 11:56 AM, Mark Shannon wrote: > The frame object is a key object in CPython. It holds the state > of a function invocation. Frame objects are allocated, initialised > and deallocated at a rapid rate. > Each extra field in the frame object requires extra work for each > and every function invocation. Fewer fields in the frame object > means less overhead for function calls, and cleaner simpler code. > > We have recently removed the f_yieldfrom field from the frame object. > (http://bugs.python.org/issue14230) > > The f_exc_type, f->f_exc_value, f->f_exc_traceback fields which handle > sys.exc_info() in generators could be moved to the generator object. > (http://bugs.python.org/issue13897) > > The f_tstate field is redundant and, it would seem, dangerous > (http://bugs.python.org/issue14432) > > The f_builtins, f_globals, f_locals fields could be combined into a > single f_namespaces struct. > (http://code.activestate.com/lists/python-dev/113381/) > > Now PEP 419 proposes adding (yet) another field to the frame object. > Please don't. > > Clean, concise data structures lead to clean, concise code. > which we all know is a "good thing" :) > > Cheers, > Mark. > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing surplus fields from the frame object and not adding any new ones.
Andrew Svetlov wrote: Do you want to create `frame` and `f_namespaces` every function call instead of single `frame` creation? f_namespaces would be part of the frame, replacing f_builtins, f_globals and f_locals. The indirection of an external object hurts performance, so it would have to be a struct within the frame. The aim is clarity; locals, globals and builtins form a trio, so should be implemented as such. On Mon, Apr 9, 2012 at 11:56 AM, Mark Shannon wrote: The frame object is a key object in CPython. It holds the state of a function invocation. Frame objects are allocated, initialised and deallocated at a rapid rate. Each extra field in the frame object requires extra work for each and every function invocation. Fewer fields in the frame object means less overhead for function calls, and cleaner simpler code. We have recently removed the f_yieldfrom field from the frame object. (http://bugs.python.org/issue14230) The f_exc_type, f->f_exc_value, f->f_exc_traceback fields which handle sys.exc_info() in generators could be moved to the generator object. (http://bugs.python.org/issue13897) The f_tstate field is redundant and, it would seem, dangerous (http://bugs.python.org/issue14432) The f_builtins, f_globals, f_locals fields could be combined into a single f_namespaces struct. (http://code.activestate.com/lists/python-dev/113381/) Now PEP 419 proposes adding (yet) another field to the frame object. Please don't. Clean, concise data structures lead to clean, concise code. which we all know is a "good thing" :) Cheers, Mark. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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() or >> time.cpu_time()) > > TBH I don't need another timer that measures CPU time (not even on > Windows). In a sense, measuring CPU time is a relic from the age of > mainframes and timesharing, where CPU time was the most precious > resource (and in some cases the unit in which other resources were > expressed for accounting purposes). In modern days, it's much more > likely that the time you're measuring is somehow related to how long a > use has to wait for some result (e.g. web response times) and here > "wait time" is just as real as CPU time. Ah. In this case, my initial proposition is correct. I re-added the pseudo-code: http://www.python.org/dev/peps/pep-0418/#deferred-api-time-perf-counter Use QueryPerformanceCounter(), or time.monotonic() or time.time(). Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 what > you're measuring). Yep. > | 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 units". > > Am I going to the wrong place to learn about these functions? Yes, the resolution is 100 ns, but the accuracy is only 1 ms in the best case (but it usually 15 ms or 10 ms). Resolution != accuracy, and only accuracy matters :-) http://www.python.org/dev/peps/pep-0418/#resolution Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Change to yield-from implementation
Mark Shannon wrote: We have recently removed the f_yieldfrom field from the frame object. (http://bugs.python.org/issue14230) Hey, wait a minute. Did anyone consider the performance effect of that change on deeply nested yield-froms? The way it was, a yield-from chain was traversed by a very tight C loop that found the end frame and resumed it directly. If I understand what you've done correctly, now it has to enter and execute a bytecode in every frame along the way. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change to yield-from implementation
2012/4/9 Greg Ewing : > Mark Shannon wrote: > >> We have recently removed the f_yieldfrom field from the frame object. >> (http://bugs.python.org/issue14230) > > > Hey, wait a minute. Did anyone consider the performance effect > of that change on deeply nested yield-froms? > > The way it was, a yield-from chain was traversed by a very > tight C loop that found the end frame and resumed it directly. > If I understand what you've done correctly, now it has to > enter and execute a bytecode in every frame along the way. I think correctness is more important that performance, though. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing surplus fields from the frame object and not adding any new ones.
So it's really no difference between three separate fields in frame and embedded struct with those fields. On Mon, Apr 9, 2012 at 1:51 PM, Mark Shannon wrote: > Andrew Svetlov wrote: >> >> Do you want to create `frame` and `f_namespaces` every function call >> instead of single `frame` creation? > > > f_namespaces would be part of the frame, replacing f_builtins, f_globals > and f_locals. The indirection of an external object hurts performance, > so it would have to be a struct within the frame. The aim is clarity; > locals, globals and builtins form a trio, so should be implemented as such. > > >> On Mon, Apr 9, 2012 at 11:56 AM, Mark Shannon wrote: >>> >>> The frame object is a key object in CPython. It holds the state >>> of a function invocation. Frame objects are allocated, initialised >>> and deallocated at a rapid rate. >>> Each extra field in the frame object requires extra work for each >>> and every function invocation. Fewer fields in the frame object >>> means less overhead for function calls, and cleaner simpler code. >>> >>> We have recently removed the f_yieldfrom field from the frame object. >>> (http://bugs.python.org/issue14230) >>> >>> The f_exc_type, f->f_exc_value, f->f_exc_traceback fields which handle >>> sys.exc_info() in generators could be moved to the generator object. >>> (http://bugs.python.org/issue13897) >>> >>> The f_tstate field is redundant and, it would seem, dangerous >>> (http://bugs.python.org/issue14432) >>> >>> The f_builtins, f_globals, f_locals fields could be combined into a >>> single f_namespaces struct. >>> (http://code.activestate.com/lists/python-dev/113381/) >>> >>> Now PEP 419 proposes adding (yet) another field to the frame object. >>> Please don't. >>> >>> Clean, concise data structures lead to clean, concise code. >>> which we all know is a "good thing" :) >>> >>> Cheers, >>> Mark. >>> >>> ___ >>> Python-Dev mailing list >>> [email protected] >>> http://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: >>> >>> http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com >> >> >> >> > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change to yield-from implementation
On Tue, 10 Apr 2012 00:24:07 +1200 Greg Ewing wrote: > Mark Shannon wrote: > > > We have recently removed the f_yieldfrom field from the frame object. > > (http://bugs.python.org/issue14230) > > Hey, wait a minute. Did anyone consider the performance effect > of that change on deeply nested yield-froms? What's the point? Apart from naïve toy examples of traversing trees, I don't think "deeply nested yield-froms" are likely to be performance-critical. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing surplus fields from the frame object and not adding any new ones.
While I agree with keeping data structures simple and clean I think conserving them forever is bad idea in general. Let's look on every particular case before making decision. On Mon, Apr 9, 2012 at 3:46 PM, Andrew Svetlov wrote: > So it's really no difference between three separate fields in frame > and embedded struct with those fields. > > On Mon, Apr 9, 2012 at 1:51 PM, Mark Shannon wrote: >> Andrew Svetlov wrote: >>> >>> Do you want to create `frame` and `f_namespaces` every function call >>> instead of single `frame` creation? >> >> >> f_namespaces would be part of the frame, replacing f_builtins, f_globals >> and f_locals. The indirection of an external object hurts performance, >> so it would have to be a struct within the frame. The aim is clarity; >> locals, globals and builtins form a trio, so should be implemented as such. >> >> >>> On Mon, Apr 9, 2012 at 11:56 AM, Mark Shannon wrote: The frame object is a key object in CPython. It holds the state of a function invocation. Frame objects are allocated, initialised and deallocated at a rapid rate. Each extra field in the frame object requires extra work for each and every function invocation. Fewer fields in the frame object means less overhead for function calls, and cleaner simpler code. We have recently removed the f_yieldfrom field from the frame object. (http://bugs.python.org/issue14230) The f_exc_type, f->f_exc_value, f->f_exc_traceback fields which handle sys.exc_info() in generators could be moved to the generator object. (http://bugs.python.org/issue13897) The f_tstate field is redundant and, it would seem, dangerous (http://bugs.python.org/issue14432) The f_builtins, f_globals, f_locals fields could be combined into a single f_namespaces struct. (http://code.activestate.com/lists/python-dev/113381/) Now PEP 419 proposes adding (yet) another field to the frame object. Please don't. Clean, concise data structures lead to clean, concise code. which we all know is a "good thing" :) Cheers, Mark. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com >>> >>> >>> >>> >> >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com > > > > -- > Thanks, > Andrew Svetlov -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change to yield-from implementation
On Mon, Apr 9, 2012 at 5:46 AM, Antoine Pitrou wrote: > On Tue, 10 Apr 2012 00:24:07 +1200 > Greg Ewing wrote: >> Mark Shannon wrote: >> >> > We have recently removed the f_yieldfrom field from the frame object. >> > (http://bugs.python.org/issue14230) >> >> Hey, wait a minute. Did anyone consider the performance effect >> of that change on deeply nested yield-froms? > > What's the point? Apart from naïve toy examples of traversing trees, I > don't think "deeply nested yield-froms" are likely to be > performance-critical. I agree with Benjamin that correctness trumps performance, but I'd also like to point out that there are other use cases besides nested iterators. If this gets used for coroutines it may not be so unusual to have a stack of nested things with on top one that loops a lot -- if each iteration incurs cost proportional to how it got there this may be a problem. But, correctness first. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing surplus fields from the frame object and not adding any new ones.
On Mon, Apr 9, 2012 at 3:51 AM, Mark Shannon wrote: > f_namespaces would be part of the frame, replacing f_builtins, f_globals > and f_locals. The indirection of an external object hurts performance, > so it would have to be a struct within the frame. The aim is clarity; > locals, globals and builtins form a trio, so should be implemented as such. How does replacing three fields with a struct containing three fields reduce the size of the frame or the overhead in creating it? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing surplus fields from the frame object and not adding any new ones.
Guido van Rossum wrote: On Mon, Apr 9, 2012 at 3:51 AM, Mark Shannon wrote: f_namespaces would be part of the frame, replacing f_builtins, f_globals and f_locals. The indirection of an external object hurts performance, so it would have to be a struct within the frame. The aim is clarity; locals, globals and builtins form a trio, so should be implemented as such. How does replacing three fields with a struct containing three fields reduce the size of the frame or the overhead in creating it? It doesn't. I think it would improve clarity, but I doubt it is worth the effort. The point I really wanted to make is that many of the fields in the frame object belong elsewhere and adding new fields to the frame object is generally a bad idea. Cheers, Mark. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing surplus fields from the frame object and not adding any new ones.
The point I really wanted to make is that many of the fields in the frame object belong elsewhere and adding new fields to the frame object is generally a bad idea. I disagree with that statement, and don't think you have offered sufficient proof of it. The structure may look irregular to you, but maybe you just need to get used to it. Factually, I don't think that *many* of the fields belong elsewhere. The majority of the fields clearly belongs where it is, and there is nothing wrong with adding new fields if there is a need for it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing surplus fields from the frame object and not adding any new ones.
On Mon, Apr 9, 2012 at 8:17 AM, Mark Shannon wrote: > Guido van Rossum wrote: >> >> On Mon, Apr 9, 2012 at 3:51 AM, Mark Shannon wrote: >>> >>> f_namespaces would be part of the frame, replacing f_builtins, f_globals >>> and f_locals. The indirection of an external object hurts performance, >>> so it would have to be a struct within the frame. The aim is clarity; >>> locals, globals and builtins form a trio, so should be implemented as >>> such. >> >> >> How does replacing three fields with a struct containing three fields >> reduce the size of the frame or the overhead in creating it? >> > > It doesn't. > I think it would improve clarity, but I doubt it is worth the effort. > > The point I really wanted to make is that many of the fields in the > frame object belong elsewhere and adding new fields to the frame object > is generally a bad idea. But is it? Consider the 'finally' proposal (not that I endorse it!) -- where would they put this info? And what is the cost really? Have you measured it? Or are you just optimizing prematurely? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: #14533: if a test has no test_main, use loadTestsFromModule.
On 4/9/2012 9:13 AM, r.david.murray wrote: http://hg.python.org/cpython/rev/eff551437abd changeset: 76176:eff551437abd user:R David Murray date:Mon Apr 09 08:55:42 2012 -0400 summary: #14533: if a test has no test_main, use loadTestsFromModule. This moves us further in the direction of using normal unittest facilities instead of specialized regrtest ones. Any test module that can be correctly run currently using 'python unittest -m test.test_xxx' can now be converted to use normal unittest test loading by simply deleting its test_main, thus no longer requiring manual maintenance of the list of tests to run. ... + if __name__ == '__main__': + unittest.main() - if __name__ == '__main__': - test_main() Being on Windows, I sometimes run single tests interactively with from test import test_xxx as t; t.test_main() Should t.unittest.main(t.__name__) work as well? Should this always work even if there is still a test_main? tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 304CC1CB5A for ; Mon, 9 Apr 2012 21:06:00 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3VRLZb6y36zMWS for ; Mon, 9 Apr 2012 21:05:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1333998360; bh=ZhGI0T6Kn0Y8JqnevpbwDXDB5j9UXzZv8e2a2phXX7Q=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=v5Unj779GoVXtqcGwg7RMYf7Q4+RyrlY4L7j0WoAqz3nivlgYdXUJwvUrXpyZX3oR D1gmggDFVyrKZRcueBy3gpNYgoNWzBE2BVFDW36BugqNNBINX8fjrwkvDhfyG0V/oy h/8h7FR2fNbyaJyViHuUjGTsVyM9YkTksivNw4qc= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 09 Apr 2012 21:05:59 +0200 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for ; Mon, 9 Apr 2012 21:05:59 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from ) id 1SHJuZ-00030q-Pl for [email protected]; Mon, 09 Apr 2012 21:05:59 +0200 Date: Mon, 09 Apr 2012 21:05:59 +0200 Message-Id: Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: [email protected] To: [email protected] Subject: [issue14004] TmV3IGNoYW5nZXNldCBiNWYwY2U0ZGRmMGMgYnkgw4lyaWMgQXJhdWpvIGluIGJyYW5jaCAnMi43 JzoKRml4IGxvbmctc3RhbmRpbmcgYnVncyB3aXRoIE1BTklGRVNULmluIHBhcnNpbmcgb24gV2lu ZG93cyAoIzY4ODQpLgpodHRwOi8vaGcucHl0aG9uLm9yZy9jcHl0aG9uL3Jldi9iNWYwY2U0ZGRm MGMK ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 363A41CBBD for ; Mon, 9 Apr 2012 21:06:00 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3VRLZb7449zMXv for ; Mon, 9 Apr 2012 21:05:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1333998360; bh=ZhGI0T6Kn0Y8JqnevpbwDXDB5j9UXzZv8e2a2phXX7Q=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=s6EE04stXBIIATauhoZuwRzAyMxzVK0IdvCVAtdt1TX7KywoGntHN2Y+9UftEwHHv i3acVM7VBTfqadTFcz16cb5NcrO9C9tgAB9tnoYJxNn1beSYEILe38nXwzVfXu9Tw0 8HYgzMq2cbHIKrvRriONhB4BKHjReqx24/bvwCuk= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 09 Apr 2012 21:05:59 +0200 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for ; Mon, 9 Apr 2012 21:05:59 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from ) id 1SHJuZ-00030q-P4 for [email protected]; Mon, 09 Apr 2012 21:05:59 +0200 Date: Mon, 09 Apr 2012 21:05:59 +0200 Message-Id: Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: [email protected] To: [email protected] Subject: [issue13193] TmV3IGNoYW5nZXNldCBiNWYwY2U0ZGRmMGMgYnkgw4lyaWMgQXJhdWpvIGluIGJyYW5jaCAnMi43 JzoKRml4IGxvbmctc3RhbmRpbmcgYnVncyB3aXRoIE1BTklGRVNULmluIHBhcnNpbmcgb24gV2lu ZG93cyAoIzY4ODQpLgpodHRwOi8vaGcucHl0aG9uLm9yZy9jcHl0aG9uL3Jldi9iNWYwY2U0ZGRm MGMK ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: #14533: if a test has no test_main, use loadTestsFromModule.
On Apr 10, 2012 2:36 AM, "Terry Reedy" wrote: > > > On 4/9/2012 9:13 AM, r.david.murray wrote: >> >> http://hg.python.org/cpython/rev/eff551437abd >> changeset: 76176:eff551437abd >> user:R David Murray >> date:Mon Apr 09 08:55:42 2012 -0400 >> summary: >> #14533: if a test has no test_main, use loadTestsFromModule. >> >> This moves us further in the direction of using normal unittest facilities >> instead of specialized regrtest ones. Any test module that can be correctly >> run currently using 'python unittest -m test.test_xxx' can now be converted to >> use normal unittest test loading by simply deleting its test_main, thus no >> longer requiring manual maintenance of the list of tests to run. > > ... >> >> + if __name__ == '__main__': >> + unittest.main() >> >> - if __name__ == '__main__': >> - test_main() > > > Being on Windows, I sometimes run single tests interactively with > > from test import test_xxx as t; t.test_main() > > Should t.unittest.main(t.__name__) work as well? > Should this always work even if there is still a test_main? Both questions have the same answer. Yes, because this is how discovery works. > > tjr > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #13165: stringbench is now available in the Tools/stringbench folder.
Some comments...
On 4/9/2012 11:09 AM, antoine.pitrou wrote:
http://hg.python.org/cpython/rev/704630a9c5d5
changeset: 76179:704630a9c5d5
user:Antoine Pitrou
date:Mon Apr 09 17:03:32 2012 +0200
summary:
Issue #13165: stringbench is now available in the Tools/stringbench folder.
...
diff --git a/Tools/stringbench/stringbench.py b/Tools/stringbench/stringbench.py
new file mode 100755
--- /dev/null
+++ b/Tools/stringbench/stringbench.py
@@ -0,0 +1,1483 @@
+
Did you mean to start with a blank line?
+# Various microbenchmarks comparing unicode and byte string performance
+# Please keep this file both 2.x and 3.x compatible!
Which versions of 2.x? In particular
+dups = {}
+dups[f.__name__] = 1
Is the use of a dict for a set a holdover that could be updated, or
intentional for back compatibility with 2.whatever and before?
+# Try with regex
+@uses_re
+@bench('s="ABC"*33; re.compile(s+"D").search((s+"D")*300+s+"E")',
+ "late match, 100 characters", 100)
+def re_test_slow_match_100_characters(STR):
+m = STR("ABC"*33)
+d = STR("D")
+e = STR("E")
+s1 = (m+d)*300 + m+e
+s2 = m+e
+pat = re.compile(s2)
+search = pat.search
+for x in _RANGE_100:
+search(s1)
If regex is added to stdlib as other than re replacement, we might want
option to use that instead or in addition to the current re.
+ Benchmark join
+
+def get_bytes_yielding_seq(STR, arg):
+if STR is BYTES and sys.version_info>= (3,):
+raise UnsupportedType
+return STR(arg)
+@bench('"A".join("")',
+ "join empty string, with 1 character sep", 100)
I am puzzled by this. Does str.join(iterable) internally branch on
whether the iterable is a str or not, so that that these timings might
be different from equivalent timings with list of strings?
What might be interesting, especially for 3.3, is timing with non-ascii
BMP and non-BMP chars both as joiner and joined.
tjr
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: #14533: if a test has no test_main, use loadTestsFromModule.
On Mon, 09 Apr 2012 13:34:25 -0400, Terry Reedy wrote: > > On 4/9/2012 9:13 AM, r.david.murray wrote: > > http://hg.python.org/cpython/rev/eff551437abd > > changeset: 76176:eff551437abd > > user:R David Murray > > date:Mon Apr 09 08:55:42 2012 -0400 > > summary: > >#14533: if a test has no test_main, use loadTestsFromModule. > > > > This moves us further in the direction of using normal unittest facilities > > instead of specialized regrtest ones. Any test module that can be correctly > > run currently using 'python unittest -m test.test_xxx' can now be converted > > to > > use normal unittest test loading by simply deleting its test_main, thus no > > longer requiring manual maintenance of the list of tests to run. > ... > > + if __name__ == '__main__': > > + unittest.main() > > > > - if __name__ == '__main__': > > - test_main() > > Being on Windows, I sometimes run single tests interactively with > > from test import test_xxx as t; t.test_main() > > Should t.unittest.main(t.__name__) work as well? That will work. t.unittest.main(t) will also work and is less typing. > Should this always work even if there is still a test_main? It will work if and only if the test can be run correctly via './python -m unittest test.test_xxx'. Not all test files in Lib/test can be run that way (though I at least am open to fixing ones that don't work). --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Upgrading tcl/tk deps
Can someone let me in on the process to upgrade tcl and tk on svn.python.org? For the VS2010 port it looks like I need to upgrade since the 8.5.9 versions do not work. They use link options that choke on 2010. Taking 8.5.11, which is the current release, seems to work out alright so far. It seems as easy as downloading the tarball and checking that in. Am I missing any official process here? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #13165: stringbench is now available in the Tools/stringbench folder.
On Mon, 09 Apr 2012 14:54:03 -0400 Terry Reedy wrote: > > > diff --git a/Tools/stringbench/stringbench.py > > b/Tools/stringbench/stringbench.py > > new file mode 100755 > > --- /dev/null > > +++ b/Tools/stringbench/stringbench.py > > @@ -0,0 +1,1483 @@ > > + > > Did you mean to start with a blank line? This is just a copy of the original file. I did not make any modifications to it. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Who are the decimal volunteers? Re: [Python-checkins] cpython: Resize the coefficient to MPD_MINALLOC also if the requested size is below
I remember that one of the concerns with cdecimal was whether it could
be maintained by anyone except Stefan (and a few people who were
already overcommitted).
If anyone (including absolute newbies) wants to step up, now would be
a good time to get involved.
A few starter questions, whose answer it would be good to document:
Why is there any need for MPD_MINALLOC at all for (immutable) numbers?
I suspect that will involve fleshing out some of the memory management
issues around dynamic decimals, as touched on here:
http://www.bytereef.org/mpdecimal/doc/libmpdec/memory.html#static-and-dynamic-decimals
On Mon, Apr 9, 2012 at 3:33 PM, stefan.krah wrote:
> http://hg.python.org/cpython/rev/170bdc5c798b
> changeset: 76197:170bdc5c798b
> parent: 76184:02ecb8261cd8
> user: Stefan Krah
> date: Mon Apr 09 20:47:57 2012 +0200
> summary:
> Resize the coefficient to MPD_MINALLOC also if the requested size is below
> MPD_MINALLOC. Previously the resize was skipped as a micro optimization.
>
> files:
> Modules/_decimal/libmpdec/mpdecimal.c | 36 --
> 1 files changed, 20 insertions(+), 16 deletions(-)
>
>
> diff --git a/Modules/_decimal/libmpdec/mpdecimal.c
> b/Modules/_decimal/libmpdec/mpdecimal.c
> --- a/Modules/_decimal/libmpdec/mpdecimal.c
> +++ b/Modules/_decimal/libmpdec/mpdecimal.c
> @@ -480,17 +480,20 @@
> {
> assert(!mpd_isconst_data(result)); /* illegal operation for a const */
> assert(!mpd_isshared_data(result)); /* illegal operation for a shared */
> -
> + assert(MPD_MINALLOC <= result->alloc);
> +
> + nwords = (nwords <= MPD_MINALLOC) ? MPD_MINALLOC : nwords;
> + if (nwords == result->alloc) {
> + return 1;
> + }
> if (mpd_isstatic_data(result)) {
> if (nwords > result->alloc) {
> return mpd_switch_to_dyn(result, nwords, status);
> }
> - }
> - else if (nwords != result->alloc && nwords >= MPD_MINALLOC) {
> - return mpd_realloc_dyn(result, nwords, status);
> - }
> -
> - return 1;
> + return 1;
> + }
> +
> + return mpd_realloc_dyn(result, nwords, status);
> }
>
> /* Same as mpd_qresize, but the complete coefficient (including the old
> @@ -500,20 +503,21 @@
> {
> assert(!mpd_isconst_data(result)); /* illegal operation for a const */
> assert(!mpd_isshared_data(result)); /* illegal operation for a shared */
> -
> - if (mpd_isstatic_data(result)) {
> - if (nwords > result->alloc) {
> - return mpd_switch_to_dyn_zero(result, nwords, status);
> - }
> - }
> - else if (nwords != result->alloc && nwords >= MPD_MINALLOC) {
> - if (!mpd_realloc_dyn(result, nwords, status)) {
> + assert(MPD_MINALLOC <= result->alloc);
> +
> + nwords = (nwords <= MPD_MINALLOC) ? MPD_MINALLOC : nwords;
> + if (nwords != result->alloc) {
> + if (mpd_isstatic_data(result)) {
> + if (nwords > result->alloc) {
> + return mpd_switch_to_dyn_zero(result, nwords, status);
> + }
> + }
> + else if (!mpd_realloc_dyn(result, nwords, status)) {
> return 0;
> }
> }
>
> mpd_uint_zero(result->data, nwords);
> -
> return 1;
> }
>
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Upgrading tcl/tk deps
Zitat von Brian Curtin : Can someone let me in on the process to upgrade tcl and tk on svn.python.org? For the VS2010 port it looks like I need to upgrade since the 8.5.9 versions do not work. They use link options that choke on 2010. Taking 8.5.11, which is the current release, seems to work out alright so far. It seems as easy as downloading the tarball and checking that in. Am I missing any official process here? Yes. There is a set of changes that you need to preserve. Tk *never* works with any recent VC compilers, so even if you use a new version, you still likely have to adjust the sources and the build process. Also, make sure Tix works. So there are two options: a) adjust the existing sources to work with the new compiler. To do so, modify tk-8.5.9.x (or whatever we currently use), then tag your modifications as tk-8.5.9. (would be .1 AFAICT), then update Tools/buildbot and PCbuild/readme.txt to refer to these. b) import new sources into tk-8.X.Y.x, then go through the changes in tk-8.5.9.x, and port over what is still needed. Again, tag your imported tree so that the Python tree refers to the tag, allowing for modifications to Tk should they be necessary. Switching to the most recent Tk release is a good idea, anyway, so b) is preferred. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Who are the decimal volunteers? Re: cpython: Resize the coefficient to MPD_MINALLOC also if the requested size is below
Jim Jewett wrote: > Why is there any need for MPD_MINALLOC at all for (immutable) numbers? > > I suspect that will involve fleshing out some of the memory management > issues around dynamic decimals, as touched on here: > http://www.bytereef.org/mpdecimal/doc/libmpdec/memory.html#static-and-dynamic-decimals MPD_MINALLOC "In order to avoid frequent resizing operations, the global variable MPD_MINALLOC guarantees a minimum amount of allocated words for the coefficient of each mpd_t. [...]" So the rationale is to avoid resizing operations. The mpd_t data type is not immutable -- I suspect no high speed library for arbitrary precision arithmetic has an immutable data type. PyDecObjects are immutable, but they have to be initialized at some point. The mpd_t struct is part of a PyDecObject and is in the position of the result operand during initialization. All operations in _decimal.c follow the same scheme: /* dec contains an mpd_t with MPD_MINALLOC words. */ dec = dec_alloc(); /* Initialization by a libmpdec function. MPD() is the accessor macro for the mpd_t. */ mpd_func(MPD(dec), x, y, ...); /* From here on dec is immutable */ Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 units". | > | > Am I going to the wrong place to learn about these functions? | | Yes, the resolution is 100 ns, but the accuracy is only 1 ms in the | best case (but it usually 15 ms or 10 ms). I understand the difference, but I can't see mention of the accuracy on the cited page, hence my question as to whether I'm looking in the right place. I need to mark up clocks with their accuracy (I've got their resolution:-) | Resolution != accuracy, and only accuracy matters :-) | http://www.python.org/dev/peps/pep-0418/#resolution I agree. But finding the accuracy seems harder than one would like. -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Thomas R. Collins wrote > This is NOT alt.peeves, as I previously suspected, but >alt.talk-about-what-you-want-but-sooner-or-later-you'll-get-flamed. alt.peeves "as you suspected" doesn't exist and never has. The _real_ alt.peeves is, and for at least the past six years has been, the literate and flamminiferous counterpart of alt.flame and the refined and brutal alternative to alt.tasteless. - Charlie Stross , educating a newbie ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 other OS sleep() uses CLOCK_MONOTONIC, I want my timer there to > use that. And if on some OS sleep() is buggy and uses the time-of-day > clock, well, I wouldn't mind if my timer used the same thing. sleep() takes a number of seconds as argument, so CLOCK_MONOTONIC should be used, not CLOCK_MONOTONIC_RAW. If I understood correctly, the unit of CLOCK_MONOTONIC is a second, whereas CLOCK_MONOTONIC_RAW may be faster or slower than a second. It looks like CLOCK_MONOTONIC_RAW was added to write a NTP server in user-space. Extract of the mail including the patch adding CLOCK_MONOTONIC_RAW to the Linux kernel: "In talking with Josip Loncaric, and his work on clock synchronization (see btime.sf.net), he mentioned that for really close synchronization, it is useful to have access to "hardware time", that is a notion of time that is not in any way adjusted by the clock slewing done to keep close time sync. Part of the issue is if we are using the kernel's ntp adjusted representation of time in order to measure how we should correct time, we can run into what Paul McKenney aptly described as "Painting a road using the lines we're painting as the guide". I had been thinking of a similar problem, and was trying to come up with a way to give users access to a purely hardware based time representation that avoided users having to know the underlying frequency and mask values needed to deal with the wide variety of possible underlying hardware counters." https://lkml.org/lkml/2008/3/19/260 Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: #14533: if a test has no test_main, use loadTestsFromModule.
On 4/9/2012 3:57 PM, R. David Murray wrote: On Mon, 09 Apr 2012 13:34:25 -0400, Terry Reedy wrote: Should t.unittest.main(t.__name__) work as well? That will work. t.unittest.main(t) will also work and is less typing. Good. The only doc for the parameter is "unittest.main(module='__main__'," with no indication other than the name 'module' that both a module object or a name is accepted (as with some file object or name interfaces). Should this always work even if there is still a test_main? It will work if and only if the test can be run correctly via './python -m unittest test.test_xxx'. Not all test files in Lib/test can be run that way (though I at least am open to fixing ones that don't work). One way to again run each would be nice. I will open an issue if I find any laggards. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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 Sat, Apr 7, 2012 at 4:56 PM, Glyph Lefkowitz wrote: > On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote: > > In any case, NTP is not the only thing that adjusts the clock, e.g. the > operating system will adjust the time for daylight savings. > > > Daylight savings time is not a clock adjustment, at least not in the sense > this thread has mostly been talking about the word "clock". It doesn't > affect the "seconds from epoch" measurement, it affects the way in which > the clock is formatted to the user. > > -glyph > even on windows where the system hardware clock is maintained in local time? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Upgrading tcl/tk deps
On 4/9/2012 5:49 PM, [email protected] wrote: Zitat von Brian Curtin : Can someone let me in on the process to upgrade tcl and tk on svn.python.org? For the VS2010 port it looks like I need to upgrade since the 8.5.9 versions do not work. They use link options that choke on 2010. Taking 8.5.11, which is the current release, seems to work out alright so far. It seems as easy as downloading the tarball and checking that in. Am I missing any official process here? Yes. There is a set of changes that you need to preserve. Tk *never* works with any recent VC compilers, so even if you use a new version, you still likely have to adjust the sources and the build process. Also, make sure Tix works. So there are two options: a) adjust the existing sources to work with the new compiler. To do so, modify tk-8.5.9.x (or whatever we currently use), then tag your modifications as tk-8.5.9. (would be .1 AFAICT), then update Tools/buildbot and PCbuild/readme.txt to refer to these. b) import new sources into tk-8.X.Y.x, then go through the changes in tk-8.5.9.x, and port over what is still needed. Again, tag your imported tree so that the Python tree refers to the tag, allowing for modifications to Tk should they be necessary. Switching to the most recent Tk release is a good idea, anyway, so b) is preferred. In particular, it should include a recent fix so that French keyboards work with tk/tkinter and hence Idle better than now. There has been more than one complaint about this. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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
Is it still? I thought they fixed that ages ago? On Mon, Apr 9, 2012 at 4:42 PM, Gregory P. Smith wrote: > > On Sat, Apr 7, 2012 at 4:56 PM, Glyph Lefkowitz > wrote: >> >> On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote: >> >> In any case, NTP is not the only thing that adjusts the clock, e.g. the >> operating system will adjust the time for daylight savings. >> >> >> Daylight savings time is not a clock adjustment, at least not in the sense >> this thread has mostly been talking about the word "clock". It doesn't >> affect the "seconds from epoch" measurement, it affects the way in which the >> clock is formatted to the user. >> >> -glyph > > > even on windows where the system hardware clock is maintained in local time? > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Upgrading tcl/tk deps
On Mon, Apr 9, 2012 at 18:41, Terry Reedy wrote: > In particular, it should include a recent fix so that French keyboards work > with tk/tkinter and hence Idle better than now. There has been more than one > complaint about this. Do you know when this was fixed or have any information about it? Tcl and Tk 8.5.11 were released Nov 4, 2011. If it was fixed after that I can look into patching our copy of whatever projects are affected. ___ Python-Dev mailing list [email protected] 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 Mon, Apr 9, 2012 at 4:46 PM, Guido van Rossum wrote: > Is it still? I thought they fixed that ages ago? > sadly, no. http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html On Mon, Apr 9, 2012 at 4:42 PM, Gregory P. Smith wrote: > > > > On Sat, Apr 7, 2012 at 4:56 PM, Glyph Lefkowitz > > > wrote: > >> > >> On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote: > >> > >> In any case, NTP is not the only thing that adjusts the clock, e.g. the > >> operating system will adjust the time for daylight savings. > >> > >> > >> Daylight savings time is not a clock adjustment, at least not in the > sense > >> this thread has mostly been talking about the word "clock". It doesn't > >> affect the "seconds from epoch" measurement, it affects the way in > which the > >> clock is formatted to the user. > >> > >> -glyph > > > > > > even on windows where the system hardware clock is maintained in local > time? > > > > > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > > -- > --Guido van Rossum (python.org/~guido) > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Upgrading tcl/tk deps
On 4/9/2012 7:53 PM, Brian Curtin wrote: On Mon, Apr 9, 2012 at 18:41, Terry Reedy wrote: In particular, it should include a recent fix so that French keyboards work with tk/tkinter and hence Idle better than now. There has been more than one complaint about this. Do you know when this was fixed or have any information about it? Tcl and Tk 8.5.11 were released Nov 4, 2011. If it was fixed after that I can look into patching our copy of whatever projects are affected. The patch is specifically for tkMacOS, 29/1/12 http://core.tcl.tk/tk/info/9844fe10b9 so it apparently does not affect Windows or what we include with Windows build. But it was a show stopper for some French Mac users, including one professor who wanted to use Python for an undergraduate course. On Mar 4, Ned Daily wrote on idle-sig list: Update: The fix has now been released in the latest ActiveState Tcl 8.5 for Mac OS X release (8.5.11.1) available here: http://www.activestate.com/activetcl/downloads It appears to fix the French keyboard tilde problem and other similar problems with composite characters, like Option-U + vowel to form "umlauted" vowels in the U.S. input method. Many thanks to Adrian Robert, Kevin Walzer, and the ActiveState team for addressing this nasty problem. If you install ActiveState Tcl 8.5.x, it will automatically be used by the python.org 2.7.x, 3.2.x, and 3.3.x 64-bit/32-bit Pythons for OS X 10.6 and 10.7. It will *not* be used by the Apple-supplied system Pythons or by 32-bit-only python.org Pythons. More details here: http://www.python.org/download/mac/tcltk/ === So the latest A.S. Windows release should be fine as the base for our Windows release. Terry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Upgrading tcl/tk deps
On Mon, Apr 9, 2012 at 20:53, Terry Reedy wrote: > On 4/9/2012 7:53 PM, Brian Curtin wrote: >> >> On Mon, Apr 9, 2012 at 18:41, Terry Reedy wrote: >>> >>> In particular, it should include a recent fix so that French keyboards >>> work >>> with tk/tkinter and hence Idle better than now. There has been more than >>> one >>> complaint about this. >> >> >> Do you know when this was fixed or have any information about it? Tcl >> and Tk 8.5.11 were released Nov 4, 2011. If it was fixed after that I >> can look into patching our copy of whatever projects are affected. > > > The patch is specifically for tkMacOS, 29/1/12 > http://core.tcl.tk/tk/info/9844fe10b9 > > so it apparently does not affect Windows or what we include with Windows > build. But it was a show stopper for some French Mac users, including one > professor who wanted to use Python for an undergraduate course. > > On Mar 4, Ned Daily wrote on idle-sig list: > > Update: The fix has now been released in the latest ActiveState Tcl 8.5 > for Mac OS X release (8.5.11.1) available here: > > http://www.activestate.com/activetcl/downloads > > It appears to fix the French keyboard tilde problem and other similar > problems with composite characters, like Option-U + vowel to form > "umlauted" vowels in the U.S. input method. Many thanks to Adrian > Robert, Kevin Walzer, and the ActiveState team for addressing this nasty > problem. > > If you install ActiveState Tcl 8.5.x, it will automatically be used by > the python.org 2.7.x, 3.2.x, and 3.3.x 64-bit/32-bit Pythons for OS X > 10.6 and 10.7. It will *not* be used by the Apple-supplied system > Pythons or by 32-bit-only python.org Pythons. More details here: > > http://www.python.org/download/mac/tcltk/ > === > > So the latest A.S. Windows release should be fine as the base for our > Windows release. > > Terry The Windows build works with 8.5.11 so I imagine we would just use that. If anyone wants to pull it all out and make it use some third-party installer that's up to them. I can try applying the relevant patches to the 8.5.11 we have, but I don't really have the time or knowledge to test them. I don't know anything about tcl/tk and don't know a whole lot about Macs. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Upgrading tcl/tk deps
In article , Brian Curtin wrote: > On Mon, Apr 9, 2012 at 20:53, Terry Reedy wrote: > > On 4/9/2012 7:53 PM, Brian Curtin wrote: > >> > >> On Mon, Apr 9, 2012 at 18:41, Terry Reedy wrote: > >>> > >>> In particular, it should include a recent fix so that French keyboards > >>> work > >>> with tk/tkinter and hence Idle better than now. There has been more than > >>> one > >>> complaint about this. [...] > The Windows build works with 8.5.11 so I imagine we would just use > that. If anyone wants to pull it all out and make it use some > third-party installer that's up to them. > > I can try applying the relevant patches to the 8.5.11 we have, but I > don't really have the time or knowledge to test them. I don't know > anything about tcl/tk and don't know a whole lot about Macs. The Tk fix Terry refers is applicable only to the OS X Aqua Cocoa Tcl/Tk 8.5 port. It has nothing to do with Windows, any other OS X Tcl/Tk, or any other platform. Further, the Tcl/TK source Martin is talking about is used only by the Windows installer builds. The python.org OS X installers do not build or supply Tcl/Tk; they link with the Apple-supplied Tcl/Tks and compatible distributions, like the ActiveState ones. So this is all a non-issue. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
