Mailman 3 May 2012 - Python-Dev

What should we do with cProfile?
by Alexandre Vassalotti 04 Jun '12

04 Jun '12

Hello, As per PEP 3108, we were supposed to merge profile/cProfile into one unified module. I initially championed the change, but other things got in the way and I have never got to the point of a useful patch. I posted some code and outlined an approach how the merge could be done. However, there still a lot of details to be worked out. So I wondering whether we should abandon the change all together or attempt it for the next release. Personally, I slightly leaning on the former option since the two modules are actually fairly different underneath even though they are used similarly. And also, because it is getting late to make such backward incompatible changes. I am willing to volunteer to push the change though if it is still desired by the community. Cheers! http://bugs.python.org/issue2919

5 4

Re: [Python-Dev] PEP 405 (built-in virtualenv) status
by Carl Meyer 03 Jun '12

03 Jun '12

On 03/15/2012 03:02 PM, Lindberg, Van wrote: > FYI, the location of the tcl/tk libraries does not appear to be set in > the virtualenv, even if tkinter is installed and working in the main > Python installation. As a result, tk-based apps will not run from a > virtualenv. Thanks for the report! I've added this to the list of open issues in the PEP and I'll look into it. Carl

6 8

Python Language Summit, Florence, July 2012
by Larry Hastings 01 Jun '12

01 Jun '12

Like Python? Like Italy? Like meetings? Then I've got a treat for you! I'll be chairing a Python Language Summit this July in historic Florence, Italy. It'll be on July 1st (the day before EuroPython starts) at the Grand Hotel Mediterraneo conference center. Language Summits are when the Python core contributors step away from their computers and get together for a day to argue in person. Email me if you're interested in attending; I can send you the final details and simultaneously get a rough headcount. Volunteers to take notes are greatly appreciated, //arry/

1 1

a new type for sys.implementation
by Eric Snow 01 Jun '12

01 Jun '12

The implementation for sys.implementation is going to use a new (but "private") type[1]. It's basically equivalent to the following: class namespace: def __init__(self, **kwargs): self.__dict__.update(kwargs) def __repr__(self): keys = (k for k in self.__dict__ if not k.startswith('_')) pairs = ("{}={!r}".format(k, self.__dict__[k]) for k in sorted(keys)) return "{}({})".format(type(self).__name__, ", ".join(pairs)) There were other options for the type, but the new type was the best fit and not hard to do. Neither the type nor its API is directly exposed publicly, but it is still accessible through "type(sys.implementation)". This brings me to a couple of questions: 1. should we make the new type un-instantiable (null out tp_new and tp_init)? 2. would it be feasible to officially add the type (or something like it) in 3.3 or 3.4? I've had quite a bit of positive feedback on the type (otherwise I wouldn't bother bringing it up). But, if we don't add a type like this to Python, I'd rather close the loophole and call it good (i.e. *not* introduce a new type by stealth). My preference is for the type (or equivalent) to be blessed in the language. Regardless of the specific details of such a type, my more immediate concern is with the impact on sys.implementation of python-dev's general sentiment in this space. -eric [1] http://bugs.python.org/issue14673

7 20

[RELEASED] Python 3.3.0 alpha 4
by Georg Brandl 31 May '12

31 May '12

On behalf of the Python development team, I'm happy to announce the fourth alpha release 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__) is based on importlib by default * The new "packaging" module (also known as distutils2, and released standalone under this name), implementing the new packaging formats and deprecating "distutils" * The new "lzma" module with LZMA/XZ support * 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 * The new "faulthandler" module that helps diagnosing crashes * The new "unittest.mock" module * The new "ipaddress" module * 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 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! (*) Please note that this document is usually finalized late in the release cycle and therefore may have stubs and missing entries at this point. -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors)

1 0

Re: [Python-Dev] [Python-checkins] cpython: Make parameterized tests in email less hackish.
by Nick Coghlan 31 May '12

31 May '12

I'm not clear on why this is a metaclass rather than a simple class decorator. On Thu, May 31, 2012 at 11:54 AM, r.david.murray <python-checkins(a)python.org> wrote: > + In a _params dictioanry, the keys become part of the name of the generated > + tests. In a _params list, the values in the list are converted into a > + string by joining the string values of the elements of the tuple by '_' and > + converting any blanks into '_'s, and this become part of the name. The > + full name of a generated test is the portion of the _params name before the > + '_params' portion, plus an '_', plus the name derived as explained above. Your description doesn't match your examples or implementation. Assuming the example and implementation are correct (and they look more sensible than the currently described approach), I believe that last sentence should be: "The full name of a generated test is a 'test_' prefix, the portion of the test function name after the '_as_' separator, plus an '_', plus the name derived as explained above." Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 1

Re: [Python-Dev] cpython: Issue #14744: Fix compilation on Windows (part 2)
by Georg Brandl 30 May '12

30 May '12

Am 29.05.2012 18:54, schrieb victor.stinner: > http://hg.python.org/cpython/rev/df0144f68d76 > changeset: 77231:df0144f68d76 > user: Victor Stinner <victor.stinner(a)gmail.com> > date: Tue May 29 18:53:56 2012 +0200 > summary: > Issue #14744: Fix compilation on Windows (part 2) All Windows buildbots are still failing the test suite, with an "invalid format string" ValueError, so I assume that is related to your string formatting speedups -- can you please have a look at it before I can tag the alpha? thanks, Georg

4 8

ur'string literal' in 3.3: make same as in 2.x?
by Terry Reedy 30 May '12

30 May '12

In 2.7, 'r' and 'ur' string literal prefixes have different effects: "When an 'r' or 'R' prefix is present, a character following a backslash is included in the string without change, and all backslashes are left in the string." "When an 'r' or 'R' prefix is used in conjunction with a 'u' or 'U' prefix, then the \uXXXX and \UXXXXXXXX escape sequences are processed while all other backslashes are left in the string." When 'u' was deleted in 3.0, the first meaning was kept. Was any thought given to restoring this difference in 3.3, along with restoring 'u', so that code using 'ur' prefixes would truly be cross-compatible? (I checked, and it has not been.) Cross-compatibility is the point of adding 'u' back, and this would give 'u' prefixes an actual, useful function even in Python 3. This issue came up today in python-list thread 'python3 raw strings and \u escapes' by 'rurpy', who uses 'ur' for re strings with unicode chars and is trying to port his code to 3.x. -- Terry Jan Reedy

2 1

Re: [Python-Dev] Property inheritance in Python
by cyberdupo56＠gmail.com 30 May '12

30 May '12

Hi, I apologize if I violate (or am violating) some sacred mailing list rules. Torsten wrote back in 2010 (http://mail.python.org/pipermail/python-dev/2010-April/099672.html) about property inheritance behavior and super(). Specifically, only fget() behavior of properties work with super(), not fset() or fdel(). I apologize if there's some obvious reason this has not been addressed since then, but it seems to be expected behavior and most Pythonic, and confused me greatly when I ran into it recently. Torsten's original thread seems to have gone as if unseen, so I hesitantly bump this topic in the hopes of a resolution. Thanks, Allen

4 3

Optimize Unicode strings in Python 3.3
by Victor Stinner 30 May '12

30 May '12

Hi, Different people are working on improving performances of Unicode strings in Python 3.3. This Python version is very different from Python 3.2 because of the PEP 393, and it is still unclear to me what is the best way to create a new Unicode string. There are different approachs: * Use the legacy (Py_UNICODE) API, PyUnicode_READY() converts the result to the canonical form. CJK codecs are still using this API. * Use a Py_UCS4 buffer and then convert to the canonical form (ASCII, UCS1 or UCS2). Approach taken by io.StringIO. io.StringIO is not only used to write, but also to read and so a Py_UCS4 buffer is a good compromise. * PyAccu API: optimized version of chunks=[]; for ...: ... chunks.append(text); return ''.join(chunks). * Two steps: compute the length and maximum character of the output string, allocate the output string and then write characters. str%args was using it. * Optimistic approach. Start with a ASCII buffer, enlarge and widen (to UCS2 and then UCS4) the buffer when new characters are written. Approach used by the UTF-8 decoder and by str%args since today. The optimistic approach uses realloc() to resize the string. It is faster than the PyAccu approach (at least for short ASCII strings), maybe because it avoids the creating of temporary short strings. realloc() looks to be efficient on Linux and Windows (at least Seven). Various notes: * PyUnicode_READ() is slower than reading a Py_UNICODE array. * Some decoders unroll the main loop to process 4 or 8 bytes (32 or 64 bits CPU) at each step. I am interested if you know other tricks to optimize Unicode strings in Python, or if you are interested to work on this topic. There are open issues related to optimizing Unicode: #11313: Speed up default encode()/decode() #12807: Optimization/refactoring for {bytearray, bytes, unicode}.strip() #14419: Faster ascii decoding #14624: Faster utf-16 decoder #14625: Faster utf-32 decoder #14654: More fast utf-8 decoding #14716: Use unicode_writer API for str.format() Victor

5 8