Mailman 3 March 2011 - Python-Dev

unittest.main() --catch parameter
by anatoly techtonik 04 Mar '11

04 Mar '11

I am looking at --help of test runner and asking the question: what is the use case for -c, --catch option? It doesn't look like it should be present in generic runner. I also can't find reasons to waste short option for it. There will be big problems with people complaining about BC break even if this option is not used by anyone. Usage: tests.py [options] [test] [...] Options: -h, --help Show this message -v, --verbose Verbose output -q, --quiet Minimal output -f, --failfast Stop on first failure -c, --catch Catch control-C and display results -b, --buffer Buffer stdout and stderr during test runs -- anatoly t.

2 5

Re: [Python-Dev] Strange occasional marshal error
by MRAB 03 Mar '11

03 Mar '11

On 03/03/2011 15:09, Graham Stratton wrote: > On Mar 2, 3:01 pm, Graham Stratton<grahamstrat...(a)gmail.com> wrote: >> We are using marshal for serialising objects before distributing them >> around the cluster, and extremely occasionally a corrupted marshal is >> produced. The current workaround is to serialise everything twice and >> check that the serialisations are the same. On the rare occasions that >> they are not, I have dumped the files for comparison. It turns out >> that there are a few positions within the serialisation where >> corruption tends to occur (these positions seem to be independent of >> the data of the size of the complete serialisation). These are: >> >> 4 bytes starting at 548867 (0x86003) >> 4 bytes starting at 4398083 (0x431c03) >> 4 bytes starting at 17595395 (0x10c7c03) >> 4 bytes starting at 19794819 (0x12e0b83) >> 4 bytes starting at 22269171 (0x153ccf3) >> 2 bytes starting at 25052819 (0x17e4693) >> 3 bytes starting at 28184419 (0x1ae0f63) > > I modified marshal.c to print when it extends the string used to write > the marshal to. This gave me these results: > >>>> s = marshal.dumps(list((i, str(i)) for i in range(1400000))) > Resizing string from 50 to 1124 bytes > Resizing string from 1124 to 3272 bytes > Resizing string from 3272 to 7568 bytes > Resizing string from 7568 to 16160 bytes > Resizing string from 16160 to 33344 bytes > Resizing string from 33344 to 67712 bytes > Resizing string from 67712 to 136448 bytes > Resizing string from 136448 to 273920 bytes > Resizing string from 273920 to 548864 bytes > Resizing string from 548864 to 1098752 bytes > Resizing string from 1098752 to 2198528 bytes > Resizing string from 2198528 to 4398080 bytes > Resizing string from 4398080 to 8797184 bytes > Resizing string from 8797184 to 17595392 bytes > Resizing string from 17595392 to 19794816 bytes > Resizing string from 19794816 to 22269168 bytes > Resizing string from 22269168 to 25052814 bytes > Resizing string from 25052814 to 28184415 bytes > Resizing string from 28184415 to 31707466 bytes > > Every corruption point occurs exactly three bytes above an extension > point (rounded to the nearest word for the last two). This clearly > isn't a coincidence, but I can't see where there could be a problem. > I'd be grateful for any pointers. > I haven't found the cause, but I have found something else I'm suspicious of in the source for Python 3.2. In marshal.c there's a function "w_object", and within that function is this: else if (PyAnySet_CheckExact(v)) { PyObject *value, *it; if (PyObject_TypeCheck(v, &PySet_Type)) w_byte(TYPE_SET, p); else w_byte(TYPE_FROZENSET, p); "w_byte" is a macro which includes an if-statement, not a function. Doesn't it need some braces? (There's are braces in the other places they're needed.)

2 1

Improvements for Porting C Extension from 2 to 3
by Sümer Cip 03 Mar '11

03 Mar '11

Hi, While porting a C extension from 2 to 3, I realized that there are some general cases which can be automated. For example, for my specific application (yappi - http://code.google.com/p/yappi/), all I need to do is following things: 1) define PyModuleDef 2) change PyString_AS_STRING calls to _PyUnicode_AsString 3) change module init code a little. It occurred to me all these kind of standart changes can be automated via a script. Not sure on the usability of this however, because of my limited knowledge on the area. Does such a tool worth being implemented? -- Sumer Cip

6 7

Re: [Python-Dev] [Python-checkins] devguide (hg_transition): Update instructions to use the new "server-side clone" button
by Éric Araujo 02 Mar '11

02 Mar '11

> user: Antoine Pitrou <solipsis(a)pitrou.net> > date: Tue Mar 01 20:51:42 2011 +0100 > summary: > Update instructions to use the new "server-side clone" button That’s seriously awesome. Where can we have a look at the implementation? A remark: Having all clones created under a dedicated namespace (say sandbox) could make the hg.python.org listing clearer, since all user clones would be grouped. Some way to edit the clone description and contact would be great. Even without that, kudos for the excellent feature. Regards

4 3

Re: [Python-Dev] devinabox: Add a script which will build CPython.
by Antoine Pitrou 02 Mar '11

02 Mar '11

On Mon, 28 Feb 2011 23:03:50 +0100 brett.cannon <python-checkins(a)python.org> wrote: > + > +if sys.platform == 'win32': > + print("See the devguide's Getting Set Up guide for building under Windows") Actually, you can also build from the command line under Windows: using Tools/buildbot/build.bat or Tools/buildbot/build-amd64.bat depending on the build you want (but perhaps it's good to teach people to use the MSVC UI, since that's the reference IDE under Windows; besides, these scripts will need MSVN installed anyway). Regards Antoine.

1 0

Re: [Python-Dev] [Python-checkins] r88676 - peps/trunk/pep-0385.txt
by Eli Bendersky 02 Mar '11

02 Mar '11

The PEP (http://www.python.org/dev/peps/pep-0385/) says in "Timeline": 2010-03-05: final conversion (tentative) I assume 2011-03-05 is meant here. Eli On Mon, Feb 28, 2011 at 20:22, antoine.pitrou <python-checkins(a)python.org>wrote: > Author: antoine.pitrou > Date: Mon Feb 28 19:22:36 2011 > New Revision: 88676 > > Log: > Update PEP 385 with latest hooks work > > > > Modified: > peps/trunk/pep-0385.txt > > Modified: peps/trunk/pep-0385.txt > > ============================================================================== > --- peps/trunk/pep-0385.txt (original) > +++ peps/trunk/pep-0385.txt Mon Feb 28 19:22:36 2011 > @@ -262,7 +262,22 @@ > on every build slave for the branch in which the changeset occurs. > > The `hooks repository`_ contains ports of these server-side hooks to > -Mercurial. One additional hook could be beneficial: > +Mercurial, as well as a couple additional ones: > + > +* check branch heads: a hook to reject pushes which create a new head on > + an existing branch. The pusher then has to merge the superfetatory > heads > + and try pushing again. > + > +* check branches: a hook to reject all changesets not on an allowed named > + branch. This hook's whitelist will have to be updated when we want to > + create new maintenance branches. > + > +* check line endings: a hook, based on the `eol extension`_, to reject all > + changesets committing files with the wrong line endings. The commits > then > + have to be stripped and redone, possibly with the `eol extension`_ > enabled > + on the comitter's computer. > + > +One additional hook could be beneficial: > > * check contributors: in the current setup, all changesets bear the > username of committers, who must have signed the contributor > @@ -285,9 +300,8 @@ > information is kept in a versioned file called ``.hgeol``, and such a > file has already been checked into the Subversion repository. > > -A hook on the server side that turns down any changegroup or changeset > -introducing inconsistent newline data can still be implemented, if > -deemed necessary. > +A hook also exists on the server side to reject any changeset > +introducing inconsistent newline data (see above). > > .. _eol extension: http://mercurial.selenic.com/wiki/EolExtension > .. _win32text extension: > http://mercurial.selenic.com/wiki/Win32TextExtension > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins >

4 3

Re: [Python-Dev] [Python-checkins] devinabox: Add a Python script which will run the test suite in the most rigorous way
by Nick Coghlan 01 Mar '11

01 Mar '11

On Tue, Mar 1, 2011 at 8:03 AM, brett.cannon <python-checkins(a)python.org> wrote: > brett.cannon pushed 3e5a61adb41d to devinabox: > > http://hg.python.org/devinabox/rev/3e5a61adb41d > changeset: 8:3e5a61adb41d > user: Brett Cannon <brett(a)python.org> > date: Fri Feb 25 17:35:37 2011 -0800 > summary: > Add a Python script which will run the test suite in the most rigorous way possible. Is there any particular reason not to stick this in the main repository somewhere, so it is available in all working copies, not just devinabox? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

4 6

Re: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
by Antoine Pitrou 01 Mar '11

01 Mar '11

On Mon, 28 Feb 2011 13:36:11 -0500 Terry Reedy <tjreedy(a)udel.edu> wrote: > > > + an existing branch. The pusher then has to merge the superfetatory heads > > 'superfetatory'? I have no idea of what this is, neither does > merriam-webster.com ;-). There are some Google hits, though... Not sure if they are of people making the same mistakes as I do ;) Regards Antoine.

7 11

Re: [Python-Dev] devinabox: Properly clean up the 'build' directory from test runs.
by Antoine Pitrou 01 Mar '11

01 Mar '11

On Mon, 28 Feb 2011 23:03:51 +0100 brett.cannon <python-checkins(a)python.org> wrote: > + try: > + subprocess.call([cmd, '-W', 'default', '-bb', '-E', '-m', 'test', '-r', > + '-w', '-u', 'all', '-j', > + str(multiprocessing.cpu_count())]) > + finally: > + os.rmdir('build') os.rmdir() won't work on a non-empty directory; you probably want shutil.rmtree() instead. Regards Antoine.

1 0

Re: [Python-Dev] [Python-checkins] r88691 - python/branches/py3k/Lib/test/test_telnetlib.py
by Jack Diederich 01 Mar '11

01 Mar '11

Much thanks. On Mon, Feb 28, 2011 at 7:41 PM, antoine.pitrou <python-checkins(a)python.org> wrote: > Author: antoine.pitrou > Date: Tue Mar 1 01:41:10 2011 > New Revision: 88691 > > Log: > Endly, fix UnboundLocalError in telnetlib > > > > Modified: > python/branches/py3k/Lib/test/test_telnetlib.py > > Modified: python/branches/py3k/Lib/test/test_telnetlib.py > ============================================================================== > --- python/branches/py3k/Lib/test/test_telnetlib.py (original) > +++ python/branches/py3k/Lib/test/test_telnetlib.py Tue Mar 1 01:41:10 2011 > @@ -17,9 +17,10 @@ > conn, addr = serv.accept() > except socket.timeout: > pass > + else: > + conn.close() > finally: > serv.close() > - conn.close() > evt.set() > > class GeneralTests(TestCase): > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins >

1 0