Mailman 3 March 2008 - Python-Dev

Backport of bytearray type and io module
by Christian Heimes March 27, 2008

March 27, 2008

Hello! I've successfully back ported the bytearray type and the io module from 3.0 to 2.6. The code is available in the branch trunk-bytearray [1]. I'm down to four failing byte tests and one failing io test. The failing byte tests are all related to pickling and subclassing. I like to get the remaining tests fixed for the upcoming release in a week. Please checkout the branch and help me figure out the remaining issues. Christian [1] svn+ssh://pythondev@svn.python.org/python/branches/trunk-bytearray

4 10

UCS-4 build on build bots
by Christian Heimes March 27, 2008

March 27, 2008

Can we have at least one build bot that compiles Python with UCS-4 unicode instead of UCS-2? Christian

2 1

fixing broken build
by Neal Norwitz March 27, 2008

March 27, 2008

Christian, Please fix the build on the various buildbots that are failing or revert your changes for unicode literals. The build failures started to occur at r61953. There were several more (~5) follow up checkins. You can find all the failures here: http://www.python.org/dev/buildbot/all/ There seem to be at least two variations for how setup.py is failing. See below. n -- Traceback (most recent call last): File "./setup.py", line 6, in <module> import sys, os, imp, re, optparse File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/optparse.py", line 71, in <module> import textwrap File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/textwrap.py", line 32, in <module> class TextWrapper: File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/textwrap.py", line 84, in TextWrapper r'(\s+|' # any whitespace File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/re.py", line 188, in compile return _compile(pattern, flags) File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/re.py", line 239, in _compile raise TypeError, "first argument must be string or compiled pattern" TypeError: first argument must be string or compiled pattern Traceback (most recent call last): File "./setup.py", line 13, in <module> from distutils.core import Extension, setup File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/distutils/core.py", line 21, in <module> from distutils.dist import Distribution File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/distutils/dist.py", line 21, in <module> from distutils.fancy_getopt import FancyGetopt, translate_longopt File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/distutils/fancy_getopt.py", line 32, in <module> longopt_xlate = string.maketrans('-', '_') File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/string.py", line 76, in maketrans return ''.join(L) UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128)

3 3

Re: [Python-Dev] httplib &c. timeouts and global state
by Alan Kennedy March 26, 2008

March 26, 2008

[This message will not be threaded properly since I wasn't subscribed at the time the original was sent] [John] > What I found in the archive is this thread (sorry for the > non-python.org URL): > > http://www.gossamer-threads.com/lists/python/dev/555039?do=post_view_thread… > > In that discussion, this issue is raised, but I don't see any resolution > that answers the objection made in issue 2451. Anyway, apologies in > advance if there was a decision here that takes account of the above > objection. The solution to the problem John descibes WAS decided back at the time of discussion of the contribution, but for some reason, that solution never made into contribution that was committed. http://www.gossamer-threads.com/lists/python/dev/555108?do=post_view_thread… http://www.gossamer-threads.com/lists/python/dev/555110?do=post_view_thread… The solution is simple, as described on the bug that John created for this issue. http://bugs.python.org/issue2451 Alan.

1 0

stable buildbots
by Neal Norwitz March 26, 2008

March 26, 2008

We need to get the tests for Python to be more stable so we can push out solid releases. In order to achieve this result, we need tests that are *100% reliable* and fail _only when there is a problem with Python_. While we aren't nearly as close to that goal as we need to be, we have to work towards it. The buildbots that have been more reliable are separated onto their own page: http://www.python.org/dev/buildbot/stable/ This is the page that should be tracked by most people. This is the page we will use to determine if Python is ready for release. All green means the release is ready to ship. This page should *always* show all green. Any change that causes any buildbot to fail, should be immediately reverted. When you commit code, make sure to refresh the stable buildbot page to ensure you haven't broken anything. The stable buildbots need to represent all major platforms, at least Windows, Mac OSX, and Linux. All of those are currently represented on the page along with several others. Unfortunately some of the tests, particularly on Windows, are not passing. We need to get these in better shape. Please help out. See my other mail for details or use the link above to find the current set of problems. As we fix more tests and more platforms become stable, I will add them to the stable page. This requires restarting the server, so I plan to do this during quiet times when all the buildbot slaves are idle. n

3 3

Re: [Python-Dev] [Python-3000] the release gods are angry at python
by Paul Moore March 26, 2008

March 26, 2008

On 26/03/2008, Thomas Heller <theller(a)ctypes.org> wrote: > What I would like to see is a way to disable certain tests on certain machines; > maybe by setting environment variables? Could this be done by something like the following (completely untested!!!! no time at the moment) change to regrtest.py? --- Lib\test\regrtest.py.orig 2008-03-26 15:36:24.519590600 +0000 +++ Lib\test\regrtest.py 2008-03-26 16:02:52.513001800 +0000 @@ -341,6 +341,12 @@ stdtests.remove(arg) nottests[:0] = args args = [] + + exclusions = os.getenv('EXCLUDE_TESTS').split() + for excl in exclusions: + if excl in stdtests: + stdtests.remove(excl) + tests = tests or args or findtests(testdir, stdtests, nottests) if single: tests = tests[:1] Paul.

1 0

Re: [Python-Dev] the release gods are angry at python
by Christian Heimes March 26, 2008

March 26, 2008

Georg Brandl schrieb: > Perhaps make it an optional resource? In the py3k branch I've assigned the audio resource to the winsound tests. Only regrtest.py -uall or -uaudio runs the winsound test. Reason: the test sound was freaking out my poor cat. :/ Christian

1 0

Py3k and asyncore/asynchat
by Daniel Arbuckle March 26, 2008

March 26, 2008

A while back, I volunteered to update asyncore and asynchat for py3k. I posted a patch, and in response to feedback posted a more complicated patch+modification. Both versions have been languishing at http://bugs.python.org/issue1563 for a couple of months now without any further feedback or action. I need some more experienced member of the community to take some sort of action: reviews and suggestions are welcome, as is advice about which version I should continue on with. Committing the patch would also be acceptable :)

11 26

Proposal: from __future__ import unicode_string_literals
by Eric Smith March 25, 2008

March 25, 2008

Following up on a python-3000 discussion about making porting from 2.6 to 3.0 easier. Martin suggested making this its own thread. This proposal is to add "from __future__ import unicode_string_literals", which would make all string literals in the importing module into unicode objects in 2.6. This is similar to the -U flag, but would only affect a single module at a time. I think history has shown that -U isn't really usable when using any number of modules, including many in the standard library. There was another proposal from Christian Heimes to add "from __future__ import py3k_literals", which would: 1) '' creates an unicode object instead of a str object 2) b'' creates a str object (aka bytes in Python 3.0) 3) 1 creates a long instead of an int 4) 1L and u'' are invalid 2) is already taken care of in 2.6, since: type(b'') == str. I don't think 3) is necessary. It's an implementation detail. 4) is really two issues. It's my understanding that there's a 2to3 fixer for both of these issues. But I'm open to debate on this. I'm willing to implement this if there's consensus on it. Eric.

5 7

Two questions about jump opcodes
by Antoine Pitrou March 25, 2008

March 25, 2008

Hi, I'm attempting some bytecode tweaks (see http://bugs.python.org/issue2459) and I've got two questions about jump instructions: - Why are there both relative and absolute jump instructions? The traditional rationale for relative jumps (apart from position-independent code) is to allow for shorter operand sizes; but Python opcodes all have the same operand size (and 16 bits is more than enough to address most bytecode arrays). - Why are relative jumps unsigned? This means they can only jump forward, and as soon as you want to jump backward you have to switch to an absolute jump... (in that regard, I don't understand what JUMP_FORWARD can possibly bring over JUMP_ABSOLUTE) Thanks for your kind answers Antoine.

4 4