Mailman 3 May 2011 - Python-Dev

PEP 386 and dev repository versions workflow
by anatoly techtonik 02 May '11

02 May '11

http://guide.python-distribute.org/quickstart.html proposes suffixing version of a module in repository with 'dev' in a way that after release of '1.0' version, the repository version is changed to '2.0dev'. This makes sense, but it is not compatible with PEP 386, which suggests using 2.0.devN, where N is a repository revision number. I'd expand PEP 386 to include 2.0dev use case. -- anatoly t.

2 1

Socket servers in the test suite
by Vinay Sajip 02 May '11

02 May '11

I've been recently trying to improve the test coverage for the logging package, and have got to a not unreasonable point: logging/__init__.py 99% (96%) logging/config.py 89% (85%) logging/handlers.py 60% (54%) where the figures in parentheses include branch coverage measurements. I'm at the point where to appreciably increase coverage, I'd need to write some test servers to exercise client code in SocketHandler, DatagramHandler and HTTPHandler. I notice there are no utility classes in test.support to help with this kind of thing - would there be any mileage in adding such things? Of course I could add test server code just to test_logging (which already contains some socket server code to exercise the configuration functionality), but rolling a test server involves boilerplate such as using a custom RequestHandler-derived class for each application. I had in mind a more streamlined approach where you can just pass a single callable to a server to handle requests, e.g. as outlined in https://gist.github.com/945157 I'd be grateful for any comments about adding such functionality to e.g. test.support. Regards, Vinay Sajip

7 14

sys.settrace: behavior doesn't match docs
by Ned Batchelder 02 May '11

02 May '11

This week I learned something new about trace functions (how to write a C trace function that survives a sys.settrace(sys.gettrace()) round-trip), and while writing up what I learned, I was surprised to discover that trace functions don't behave the way I thought, or the way the docs say they behave. The docs say: The trace function is invoked (with /event/ set to 'call') whenever a new local scope is entered; it should return a reference to a local trace function to be used that scope, or None if the scope shouldn't be traced. The local trace function should return a reference to itself (or to another function for further tracing in that scope), or None to turn off tracing in that scope. It's that last part that's wrong: returning None from the trace function only has an effect on the first call in a new frame. Once the trace function returns a function for a frame, returning None from subsequent calls is ignored. A "local trace function" can't turn off tracing in its scope. To demonstrate: import sys UPTO_LINE = 1 def t(frame, event, arg): num = frame.f_lineno print("line %d" % num) if num < UPTO_LINE: return t def try_it(): print("twelve") print("thirteen") print("fourteen") print("fifteen") UPTO_LINE = 1 sys.settrace(t) try_it() UPTO_LINE = 13 sys.settrace(t) try_it() Produces: line 11 twelve thirteen fourteen fifteen line 11 line 12 twelve line 13 thirteen line 14 fourteen line 15 fifteen line 15 The first call to try_it() returns None immediately, preventing tracing for the rest of the function. The second call returns None at line 13, but the rest of the function is traced anyway. This behavior is the same in all versions from 2.3 to 3.2, in fact, the 100 lines of code in sysmodule.c responsible for Python tracing functions are completely unchanged through those versions. (A deeper mystery that I haven't looked into yet is why Python 3.x intersperses all of these lines with "line 18" interjections.) I'm writing this email because I'm not sure whether this is a behavior bug or a doc bug. One of them is wrong, since they disagree. The documented behavior makes sense, and is what people have all along thought the trace function did. The actual behavior is a bit more complicated to explain, but is what people have actually been experiencing. FWIW, PyPy implements the documented behavior. Should we fix the code or the docs? I'd be glad to supply a patch for either. --Ned.

4 4

PyObject_RichCompareBool identity shortcut
by Hrvoje Niksic 01 May '11

01 May '11

The other day I was surprised to learn this: >>> nan = float('nan') >>> nan == nan False >>> [nan] == [nan] True # also True in tuples, dicts, etc. # also: >>> l = [nan] >>> nan in l True >>> l.index(nan) 0 >>> l[0] == nan False The identity test is not in container comparators, but in PyObject_RichCompareBool: /* Quick result when objects are the same. Guarantees that identity implies equality. */ if (v == w) { if (op == Py_EQ) return 1; else if (op == Py_NE) return 0; } The guarantee referred to in the comment is not only (AFAICT) undocumented, but contradicts the documentation, which states that the result should be the "equivalent of o1 op o2". Calling PyObject_RichCompareBool is inconsistent with calling PyObject_RichCompare and converting its result to bool manually, something that wrappers (C++) and generators (cython) might reasonably want to do themselves, for various reasons. If this is considered a bug, I can open an issue. Hrvoje

22 129

Python 3.2.1
by Georg Brandl 01 May '11

01 May '11

Hi, I'd like to release Python 3.2.1 on May 21, with a release candidate on May 14. Please bring any issues you think need to be fixed in it to my attention by assigning "release blocker" status in the tracker. Georg

2 1

2to3 status, repositories and HACKING guide
by anatoly techtonik 01 May '11

01 May '11

Hi, Currently 2to3 page at http://wiki.python.org/moin/2to3 lists http://svn.python.org/view/sandbox/trunk/2to3 as a repository for 2to3 tool. There is also an outdated repository at http://hg.python.org/ and the page says that the code is finally integrated into CPython 2.6 - you can see it at http://hg.python.org/cpython/file/default/Lib/lib2to3. So, what version is more up-to-date? In svn repository there is a HACKING guide advising to use find_pattern.py script for writing new fixer. However, there is no find_pattern.py in CPython repository, no HACKING guide, no any documentation about how to write fixers or description of PATTERN format. Did I miss something? -- anatoly t.

2 4