Mailman 3 September 2012 - Python-Dev

what´s new 3.3
by Kristján Valur Jónsson 04 Oct '12

04 Oct '12

Hi there. Not having kept up, I realized I failed to contribute to the What's new thingie. Here's stuff I remember working on and putting in: 1. pickling support for built in iterators (#14288) 2. inter process socket duplication for windows (#14310) 3. Progress callback for gc module (#10576) 4. Faster locking on windows (#15038) DiSome of this should probably be mentioned in the What's new document, even if only in its online version. K

3 2

Stdlib and timezones, again
by Lennart Regebro 04 Oct '12

04 Oct '12

With 3.3 out, it's time to bring up something for 3.4. And it's about pytz and stdlib, basically. And we have been over that again, but I have a proposal anyway. The problem with including pytz in the stdlib is that it contains the tz/zoneinfo/Olson database, and it updates much more often than Python does. I propose to solve this problem in the following way: 1. Merge the functionality of pytz into the stdlib datetime module. That means extending datetime.tzinfo with the localize() function and and adding a top-level datetime.timezone() function. any other extra functionality pytz has. 2. The datetime.timezone() function will work as the pytz.timezone() function, ie return a tzinfo object from the tz database. 3. However, Python will not include the database. Instead it will use the one that the OS provides, if it provides one (ie Unices, including OS X if I remember correctly). 4. On any other OS, datetime.timezone() will return an error explaining that no tz database can be found, but that it is available in the module 'pytzdata' which then will need to be created. If this module is installed, the datetime.timezone() function will prefer that database before the OS database. 5. We can also consider implementing something like the get_localzone() function of my module tzlocal. This solves two problems. i. We have real, useful timezone support in Python. For Unix, it's included, for all other systems, it's just an extra module. The extra module can also be installed to give Python up to date tz information even when the operating system is outdated and unsupported and no longer receiving updates. ii. pytz is_dst flag becomes included in stdlib, solving one of the few imperfections in the current library. What do you say? Is this a path worth pursuing? //Lennart

23 77

experimental: Misc/NEWS included in docs
by Georg Brandl 02 Oct '12

02 Oct '12

Hi, at http://docs.python.org/3.3/whatsnew/news.html, there is now a rendering of Misc/NEWS with tracker links and a crude filtering capability. I thought that this will complement the "whatsnew" documents nicely for people looking for more detail. Please let me know if it's useful, or what could be done to make it *more* useful. cheers, Georg

6 6

[RELEASED] Python 3.3.0
by Georg Brandl 02 Oct '12

02 Oct '12

On behalf of the Python development team, I'm delighted to announce the Python 3.3.0 final release. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. Major new features and changes in the 3.3 release series are: * PEP 380, syntax for delegating to a subgenerator ("yield from") * PEP 393, flexible string representation (doing away with the distinction between "wide" and "narrow" Unicode builds) * A C implementation of the "decimal" module, with up to 120x speedup for decimal-heavy applications * The import system (__import__) now based on importlib by default * The new "lzma" module with LZMA/XZ support * PEP 397, a Python launcher for Windows * PEP 405, virtual environment support in core * PEP 420, namespace package support * PEP 3151, reworking the OS and IO exception hierarchy * PEP 3155, qualified name for classes and functions * PEP 409, suppressing exception context * PEP 414, explicit Unicode literals to help with porting * PEP 418, extended platform-independent clocks in the "time" module * PEP 412, a new key-sharing dictionary implementation that significantly saves memory for object-oriented code * PEP 362, the function-signature object * The new "faulthandler" module that helps diagnosing crashes * The new "unittest.mock" module * The new "ipaddress" module * The "sys.implementation" attribute * A policy framework for the email package, with a provisional (see PEP 411) policy that adds much improved unicode support for email header parsing * A "collections.ChainMap" class for linking mappings to a single unit * Wrappers for many more POSIX functions in the "os" and "signal" modules, as well as other useful functions such as "sendfile()" * Hash randomization, introduced in earlier bugfix releases, is now switched on by default In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.0 visit: http://www.python.org/download/releases/3.3.0/ This is a production release, please report any bugs to http://bugs.python.org/ Enjoy! -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors)

13 15

Benchmarking Python 3.3 against Python 2.7 (wide build)
by Brett Cannon 01 Oct '12

01 Oct '12

I am presenting the talk "Python 3.3: Trust Me, It's Better Than 2.7" as PyCon Argentina and Brasil (and US if they accept the talk). As part of that talk I need to be able to benchmark Python 3.3 against 2.7 (both from tip) using the unladen benchmarks (which now include benchmarks from PyPy that can be relatively easily ported to Python 3). To make sure the unladen benchmarks run fine against Python 3.3, I did a fast run of the benchmarks. I figured people might be interested in the quick-and-dirty results on my 2 GHz Intel Core i7 MacBook Pro w/ 8 GB RAM and no attempt to control for performance beyond not actively browsing the web. As I said, quick-and-dirty and not authoritative; all done just to make sure all the benchmarks could run to completion (including the django, html5lib, and genshi benchmarks which are only on my laptop ATM until those projects cut a release with official Python 3 support). One thing to keep in mind is that many benchmarks use a raw str for things, so the benchmarks often compare Python 2.7 str vs. Python 3.3 str (i.e. str vs. unicode). While this might seem unfair, this is what real-world comparisons in performance will be from users so it's an (somewhat unfair) comparison that we just have to live with. I might take the time to try to make some tests run under both raw strings and unicode so both comparisons are available. If you care about helping out with the benchmarks (e.g. helping spot where the iteration counts should be higher, etc.) then head over to the speed@mailing list. > python3 perf.py -T --basedir ../benchmarks -f -b py3k ../cpython/builds/2.7-wide/bin/python ../cpython/builds/3.3/bin/python3.3 ... output about the command line for the benchmarks ... ### 2to3 ### 0.785234 -> 0.722169: 1.09x faster ### call_method ### Min: 0.491433 -> 0.414841: 1.18x faster Avg: 0.493640 -> 0.416564: 1.19x faster Significant (t=127.21) Stddev: 0.00170 -> 0.00162: 1.0513x smaller ### call_method_slots ### Min: 0.492749 -> 0.416280: 1.18x faster Avg: 0.497888 -> 0.419275: 1.19x faster Significant (t=61.72) Stddev: 0.00433 -> 0.00237: 1.8304x smaller ### call_method_unknown ### Min: 0.575536 -> 0.427234: 1.35x faster Avg: 0.577286 -> 0.433428: 1.33x faster Significant (t=66.09) Stddev: 0.00117 -> 0.00835: 7.1621x larger ### call_simple ### Min: 0.413011 -> 0.338923: 1.22x faster Avg: 0.415862 -> 0.340699: 1.22x faster Significant (t=111.94) Stddev: 0.00223 -> 0.00134: 1.6616x smaller ### chaos ### Min: 0.375286 -> 0.435456: 1.16x slower Avg: 0.382798 -> 0.459515: 1.20x slower Significant (t=-5.01) Stddev: 0.01116 -> 0.03234: 2.8980x larger ### fastpickle ### Min: 0.853560 -> 0.770580: 1.11x faster Avg: 0.879498 -> 0.776249: 1.13x faster Significant (t=8.24) Stddev: 0.02771 -> 0.00407: 6.7995x smaller ### float ### Min: 0.476596 -> 0.391101: 1.22x faster Avg: 0.486164 -> 0.411553: 1.18x faster Significant (t=9.07) Stddev: 0.01049 -> 0.01511: 1.4411x larger ### formatted_logging ### Min: 0.346703 -> 0.451643: 1.30x slower Avg: 0.351218 -> 0.454626: 1.29x slower Significant (t=-51.50) Stddev: 0.00376 -> 0.00246: 1.5265x smaller ### genshi ### Min: 0.275107 -> 0.294309: 1.07x slower Avg: 0.287433 -> 0.299026: 1.04x slower Significant (t=-3.82) Stddev: 0.01077 -> 0.00467: 2.3044x smaller ### go ### Min: 0.719160 -> 0.781042: 1.09x slower Avg: 0.729322 -> 0.798135: 1.09x slower Significant (t=-8.54) Stddev: 0.01300 -> 0.01248: 1.0415x smaller ### hexiom2 ### 203.842661 -> 187.107363: 1.09x faster ### iterative_count ### Min: 0.145088 -> 0.153285: 1.06x slower Avg: 0.146369 -> 0.154425: 1.06x slower Significant (t=-9.21) Stddev: 0.00134 -> 0.00142: 1.0569x larger ### json_dump_v2 ### Min: 3.512367 -> 4.040813: 1.15x slower Avg: 3.521879 -> 4.057966: 1.15x slower Significant (t=-64.29) Stddev: 0.01071 -> 0.01526: 1.4247x larger ### json_load ### Min: 1.024560 -> 0.642353: 1.60x faster Avg: 1.025255 -> 0.644000: 1.59x faster Significant (t=426.59) Stddev: 0.00049 -> 0.00194: 3.9240x larger ### mako_v2 ### Min: 0.137584 -> 0.287701: 2.09x slower Avg: 0.140620 -> 0.293204: 2.09x slower Significant (t=-296.14) Stddev: 0.00243 -> 0.00272: 1.1195x larger ### meteor_contest ### Min: 0.284739 -> 0.254285: 1.12x faster Avg: 0.286174 -> 0.255323: 1.12x faster Significant (t=38.02) Stddev: 0.00124 -> 0.00133: 1.0725x larger ### nbody ### Min: 0.491416 -> 0.336127: 1.46x faster Avg: 0.493339 -> 0.337467: 1.46x faster Significant (t=185.50) Stddev: 0.00164 -> 0.00092: 1.7927x smaller ### normal_startup ### Min: 0.639285 -> 0.898157: 1.40x slower Avg: 0.645513 -> 0.901586: 1.40x slower Significant (t=-90.10) Stddev: 0.00575 -> 0.00270: 2.1309x smaller ### nqueens ### Min: 0.399351 -> 0.429575: 1.08x slower Avg: 0.403643 -> 0.430284: 1.07x slower Significant (t=-9.83) Stddev: 0.00603 -> 0.00053: 11.3092x smaller ### pathlib ### Min: 0.137462 -> 0.170506: 1.24x slower Avg: 0.145370 -> 0.172849: 1.19x slower Significant (t=-11.09) Stddev: 0.01232 -> 0.00128: 9.6403x smaller ### pidigits ### Min: 0.400265 -> 0.379307: 1.06x faster Avg: 0.401755 -> 0.381171: 1.05x faster Significant (t=14.65) Stddev: 0.00259 -> 0.00178: 1.4496x smaller ### raytrace ### Min: 1.770596 -> 1.958350: 1.11x slower Avg: 1.773719 -> 1.968401: 1.11x slower Significant (t=-44.19) Stddev: 0.00439 -> 0.00882: 2.0099x larger ### regex_effbot ### Min: 0.076566 -> 0.098124: 1.28x slower Avg: 0.077491 -> 0.098696: 1.27x slower Significant (t=-54.47) Stddev: 0.00052 -> 0.00069: 1.3227x larger ### regex_v8 ### Min: 0.091530 -> 0.109116: 1.19x slower Avg: 0.092308 -> 0.113627: 1.23x slower Significant (t=-5.72) Stddev: 0.00088 -> 0.00829: 9.4271x larger ### richards ### Min: 0.257974 -> 0.232134: 1.11x faster Avg: 0.259248 -> 0.234325: 1.11x faster Significant (t=23.80) Stddev: 0.00144 -> 0.00185: 1.2823x larger ### simple_logging ### Min: 0.326569 -> 0.416797: 1.28x slower Avg: 0.331694 -> 0.418844: 1.26x slower Significant (t=-36.32) Stddev: 0.00523 -> 0.00122: 4.3004x smaller ### spectral_norm ### Min: 0.483011 -> 0.741558: 1.54x slower Avg: 0.487128 -> 0.749741: 1.54x slower Significant (t=-57.40) Stddev: 0.00512 -> 0.00886: 1.7299x larger ### startup_nosite ### Min: 0.220444 -> 0.374521: 1.70x slower Avg: 0.222773 -> 0.376785: 1.69x slower Significant (t=-176.17) Stddev: 0.00166 -> 0.00221: 1.3331x larger ### threaded_count ### Min: 0.171352 -> 0.151892: 1.13x faster Avg: 0.183180 -> 0.153634: 1.19x faster Significant (t=8.12) Stddev: 0.00801 -> 0.00140: 5.7241x smaller ### unpack_sequence ### Min: 0.000075 -> 0.000061: 1.23x faster Avg: 0.000101 -> 0.000065: 1.54x faster Significant (t=206.90) Stddev: 0.00001 -> 0.00000: 3.2374x smaller The following not significant results are hidden, use -v to show them: chameleon, fannkuch, fastunpickle, regex_compile, silent_logging ### django ### Min: 0.868956 -> 0.894571: 1.03x slower Avg: 0.873620 -> 0.905274: 1.04x slower Significant (t=-6.97) Stddev: 0.00313 -> 0.00966: 3.0912x larger ### genshi ### Min: 0.269615 -> 0.286348: 1.06x slower Avg: 0.272206 -> 0.290708: 1.07x slower Significant (t=-12.29) Stddev: 0.00253 -> 0.00526: 2.0793x larger ### html5lib ### 12.279808 -> 11.862586: 1.04x faster

7 15

Re: [Python-Dev] benchmarks: Force map to a list to guarantee the calculations are performed under
by Antoine Pitrou 30 Sep '12

30 Sep '12

On Mon, 1 Oct 2012 01:00:42 +0200 (CEST) brett.cannon <python-checkins(a)python.org> wrote: > http://hg.python.org/benchmarks/rev/e9f911fd9bd3 > changeset: 184:e9f911fd9bd3 > user: Brett Cannon <brett(a)python.org> > date: Sun Sep 30 19:00:32 2012 -0400 > summary: > Force map to a list to guarantee the calculations are performed under > Python 3. [...] > def eval_times_u(func, u): > - return map(func, ((i,u) for i in xrange(len(list(u))))) > + return list(imap(func, ((i,u) for i in xrange(len(list(u)))))) Ugh, can't you use a list comprehension instead? The code would be much more idiomatic. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net

2 1

Failed issue tracker submission
by Python tracker 30 Sep '12

30 Sep '12

The node specified by the designator in the subject of your message ("16304") does not exist. Subject was: "[issue16304]" Mail Gateway Help ================= Incoming messages are examined for multiple parts: . In a multipart/mixed message or part, each subpart is extracted and examined. The text/plain subparts are assembled to form the textual body of the message, to be stored in the file associated with a "msg" class node. Any parts of other types are each stored in separate files and given "file" class nodes that are linked to the "msg" node. . In a multipart/alternative message or part, we look for a text/plain subpart and ignore the other parts. . A message/rfc822 is treated similar tomultipart/mixed (except for special handling of the first text part) if unpack_rfc822 is set in the mailgw config section. Summary ------- The "summary" property on message nodes is taken from the first non-quoting section in the message body. The message body is divided into sections by blank lines. Sections where the second and all subsequent lines begin with a ">" or "|" character are considered "quoting sections". The first line of the first non-quoting section becomes the summary of the message. Addresses --------- All of the addresses in the To: and Cc: headers of the incoming message are looked up among the user nodes, and the corresponding users are placed in the "recipients" property on the new "msg" node. The address in the From: header similarly determines the "author" property of the new "msg" node. The default handling for addresses that don't have corresponding users is to create new users with no passwords and a username equal to the address. (The web interface does not permit logins for users with no passwords.) If we prefer to reject mail from outside sources, we can simply register an auditor on the "user" class that prevents the creation of user nodes with no passwords. Actions ------- The subject line of the incoming message is examined to determine whether the message is an attempt to create a new item or to discuss an existing item. A designator enclosed in square brackets is sought as the first thing on the subject line (after skipping any "Fwd:" or "Re:" prefixes). If an item designator (class name and id number) is found there, the newly created "msg" node is added to the "messages" property for that item, and any new "file" nodes are added to the "files" property for the item. If just an item class name is found there, we attempt to create a new item of that class with its "messages" property initialized to contain the new "msg" node and its "files" property initialized to contain any new "file" nodes. Triggers -------- Both cases may trigger detectors (in the first case we are calling the set() method to add the message to the item's spool; in the second case we are calling the create() method to create a new node). If an auditor raises an exception, the original message is bounced back to the sender with the explanatory message given in the exception. Return-Path: <python-dev(a)python.org> X-Original-To: report(a)bugs.python.org Delivered-To: roundup+tracker(a)psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id C96C81CA8C for <report(a)bugs.python.org>; Mon, 1 Oct 2012 00:05:31 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3XVLKR40JNzNYF for <report(a)bugs.python.org>; Mon, 1 Oct 2012 00:05:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1349042731; bh=VvsXcY86pi/c+BeJIZc+70zwVxaiJ7YyKuEt7uYQ3Tc=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-Id:Date; b=JIb9A8mKbs/8mEf6lMLk3yCyEqivXstaCqDmc1Bx/B8VveRxdmlBnXCIdktlJpDXA e+ffB/whCObLiza0eN0IM8SVH012oUCUHsjGyE/9KMYXzgDLjqGhVQl65OD7lZ0did Go+K7962YIYqsKcJFoEDsTBu0OKNroH9FqedZq1M= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 01 Oct 2012 00:05:31 +0200 Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72]) by mail.python.org (Postfix) with ESMTP for <report(a)bugs.python.org>; Mon, 1 Oct 2012 00:05:30 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: python-dev(a)python.org To: report(a)bugs.python.org Subject: [issue16304] Message-Id: <3XVLKR40JNzNYF(a)mail.python.org> Date: Mon, 1 Oct 2012 00:05:31 +0200 (CEST) TmV3IGNoYW5nZXNldCA0MjU4MjQ4YTQ0YzcgYnkgTmFkZWVtIFZhd2RhIGluIGJyYW5jaCAnMy4z JzoKSXNzdWUgIzE2MzA0OiBGdXJ0aGVyIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50cyBmb3IgQloy RmlsZS4KaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvNDI1ODI0OGE0NGM3CgoKTmV3 IGNoYW5nZXNldCBhYmI1YzViZGU4NzIgYnkgTmFkZWVtIFZhd2RhIGluIGJyYW5jaCAnZGVmYXVs dCc6Ck1lcmdlOiAjMTYzMDQ6IEZ1cnRoZXIgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIGZvciBC WjJGaWxlLgpodHRwOi8vaGcucHl0aG9uLm9yZy9jcHl0aG9uL3Jldi9hYmI1YzViZGU4NzIK

1 0

Re: [Python-Dev] [Python-checkins] cpython (3.3): Change libmpdec to use ANSI code in strict ansi mode as inline asm isn't
by Stefan Krah 30 Sep '12

30 Sep '12

christian.heimes <python-checkins(a)python.org> wrote: > +/* ASM isn't available in strict ansi C mode */ > +#if defined(ASM) && defined(__STRICT_ANSI__) > + #undef ASM > + #define ANSI > +#endif I'm not too fond of this solution: the libmpdec build output should always be accurate. Now you have ... -ansi -DCONFIG_64=1 -DASM=1 ... but the build is silently non-asm. Like for pymath.c, __asm__ is tested for and selected in ./configure. So I'll replace asm with __asm__, same as in pymath.c and ceval.c. Stefan Krah

1 1

buildbot with -O
by Benjamin Peterson 30 Sep '12

30 Sep '12

In light of issue #16046, I think it would be helpful to have a buildbot running the testsuite with -O enabled. -- Regards, Benjamin

4 5

[RELEASED] Python 3.3.0 release candidate 3
by Georg Brandl 29 Sep '12

29 Sep '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I'm delighted to announce the third release candidate of Python 3.3.0. This is a preview release, and its use is not recommended in production settings. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. Major new features and changes in the 3.3 release series are: * PEP 380, syntax for delegating to a subgenerator ("yield from") * PEP 393, flexible string representation (doing away with the distinction between "wide" and "narrow" Unicode builds) * A C implementation of the "decimal" module, with up to 80x speedup for decimal-heavy applications * The import system (__import__) now based on importlib by default * The new "lzma" module with LZMA/XZ support * PEP 397, a Python launcher for Windows * PEP 405, virtual environment support in core * PEP 420, namespace package support * PEP 3151, reworking the OS and IO exception hierarchy * PEP 3155, qualified name for classes and functions * PEP 409, suppressing exception context * PEP 414, explicit Unicode literals to help with porting * PEP 418, extended platform-independent clocks in the "time" module * PEP 412, a new key-sharing dictionary implementation that significantly saves memory for object-oriented code * PEP 362, the function-signature object * The new "faulthandler" module that helps diagnosing crashes * The new "unittest.mock" module * The new "ipaddress" module * The "sys.implementation" attribute * A policy framework for the email package, with a provisional (see PEP 411) policy that adds much improved unicode support for email header parsing * A "collections.ChainMap" class for linking mappings to a single unit * Wrappers for many more POSIX functions in the "os" and "signal" modules, as well as other useful functions such as "sendfile()" * Hash randomization, introduced in earlier bugfix releases, is now switched on by default In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.0 visit: http://www.python.org/download/releases/3.3.0/ Please consider trying Python 3.3.0 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBf+0cACgkQN9GcIYhpnLBqfgCglbN63XUr2m4Ya4ff8Hza1Axl SgMAniQZRJi8uYfeqltf5/G4QV/+SdWT =KXTo -----END PGP SIGNATURE-----

14 23