Mailman 3 November 2009 - Python-Dev

People want CPAN :-)
by ssteinerX＠gmail.com Nov. 10, 2009

Nov. 10, 2009

On Nov 7, 2009, at 3:20 AM, Ben Finney wrote: > Guido van Rossum <guido(a)python.org> writes: > >> On Fri, Nov 6, 2009 at 2:52 PM, David Lyon >> <david.lyon(a)preisshare.net> wrote: >>> > I think buildbot-style test runs for PyPI packages would raise average > package quality on PyPI. Please excuse the cross-post but I wanted to make sure that all these "CPAN for Python" discussions got this message and I've lost track of which list which … [View More]part of what discussion had occurred on. We are currently extending our distutils/Distribute test system to include installation of a broad range of packages as part of the pre- release process for a future release of Distribute and as part of our "smoke" test for distutils/Distribute. Eventually, the goal is to integrate this with our buildbot system but that's a ways off. Our goal is to install a range of packages and, where practicable, actually run and record any errors with the packages' individual test suites. Right now, our "smoke" test only does Twisted and numpy. We've discussed how to collect test results from Twisted trial and we'll be working on similar things for other test runners (nose et al.). For Twisted, we're going to install and test both the current release version and an svn checkout from trunk. It would be an extension of that concept to install and test *all* packages from PyPI but would, obviously, take considerable horsepower (and time) to run such an exhaustive test (especially if we're talking about 2.4?, 2.5, 2.6, 2.7, and 3.1+. Right now I'm extending the configuration file for our smoke test to allow for various test runners (e.g. nose, twisted trial, etc.) so we can "smoke out" more installation problems and/or failed tests after installation. For the first pass, I'm just focusing on Twisted and trial, then numpy, then finding packages that support nose so that I can collect the data on what ran, what passed, and what didn't. I'm planning on collecting this all in a database and making some simple API so that it can be mined by very simple apps later. At the point where that infrastructure is in place, we could pretty easily mine the data to do all kinds of crazy things people have mentioned like: * A ranking system of test coverage * Complexity analysis * Test coverage * Run pylint, pyflakes, 2to3, whatever automated measurement tools over the code * Send test failure messages to maintainers (maybe with opt-in in the new meta-data). * Whatever! We're actively working on this right now; anyone who wants to lend a hand is welcome to contact me off-list and we can talk about what types of things we are needing and where we could use a hand. All in all, I think this could be a big leap forward for the Python distribution ecosystem whether or not we eventually write the PyPan I wished for as a new Perl refugee. Thanks, S [View Less]

3 3

Python 2.6: OverflowError: signed integer is greater than maximum
by Jasper Lievisse Adriaanse Nov. 9, 2009

Nov. 9, 2009

Hi, while trying to get Python 2.6 working on OpenBSD/sgi (64-bit port) I ran into the following during build: OverflowError: signed integer is greater than maximum I ran the command that triggered this by hand with -v added: (sgi Python-2.6.3 40)$ export PATH; PATH="`pwd`:$PATH"; export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; export EXE; EXE=""; cd ./Lib/plat-openbsd4; ./regen python$EXE -v ../../Tools/scripts/h2py.py -i '(u_long)' /… [View More]usr/include/netinet/in.h # installing zipimport hook import zipimport # builtin # installed zipimport hook # /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.pyc matches /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.py import site # precompiled from /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.pyc 'import site' failed; traceback: Traceback (most recent call last): File "/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.py", line 61, in <module> import sys OverflowError: signed integer is greater than maximum import encodings # directory /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings # /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.pyc matches /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.py import encodings # precompiled from /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.pyc Python 2.6.3 (r263:75183, Nov 6 2009, 09:50:33) [GCC 3.3.5 (propolice)] on openbsd4 Type "help", "copyright", "credits" or "license" for more information. # /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.pyc matches /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.py import re # precompiled from /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.pyc Traceback (most recent call last): File "../../Tools/scripts/h2py.py", line 24, in <module> import sys, re, getopt, os File "/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.py", line 104, in <module> import sys OverflowError: signed integer is greater than maximum # clear __builtin__._ # clear sys.path # clear sys.argv # clear sys.ps1 # clear sys.ps2 # clear sys.exitfunc # clear sys.exc_type # clear sys.exc_value # clear sys.exc_traceback # clear sys.last_type # clear sys.last_value # clear sys.last_traceback # clear sys.path_hooks # clear sys.path_importer_cache # clear sys.meta_path # clear sys.flags # clear sys.float_info # restore sys.stdin # restore sys.stdout # restore sys.stderr # cleanup __main__ # cleanup[1] zipimport # cleanup[1] signal # cleanup[1] exceptions # cleanup[1] _warnings # cleanup sys # cleanup __builtin__ # cleanup ints: 3 unfreed ints # cleanup floats (sgi plat-openbsd4 41)$ Does anyone know what's going on here, or how to fix it? I can provide a full build and configure log if needed. Cheers, Jasper -- "Intelligence should guide our actions, but in harmony with the texture of the situation at hand" -- Francisco Varela [View Less]

3 3

PEP 3003 - Python Language Moratorium
by Guido van Rossum Nov. 9, 2009

Nov. 9, 2009

I've checked draft (!) PEP 3003, "Python Language Moratorium", into SVN. As authors I've listed Jesse, Brett and myself. On python-ideas the moratorium idea got fairly positive responses (more positive than I'd expected, in fact) but I'm bracing myself for fierce discussion here on python-dev. It's important to me that if if this is accepted it is a "rough consensus" decision (working code we already have plenty of :-), not something enforced by a vocal minority or an influential individual … [View More]

42 100

Updates to XP-4 and FreeBSD build slaves
by David Bolen Nov. 9, 2009

Nov. 9, 2009

I think in a prior discussion, it was suggested that build slave updates were ok for this list - I apologize to those who may not be interested. I've just completed some updates to my two build slaves. XP-4 is now running XP Pro SP3 (was SP2) and is using the full version of VS 2008 (was previously using Express). FreeBSD is now running FreeBSD 6.4-RELEASE (was 6.2-RELEASE). Both are new VMs, and also now use the latest buildbot (0.7.11p3) release. For at least the next few days they are … [View More]

1 0

Re: [Python-Dev] PEP 3003 - Python Language Moratorium
by exarkun＠twistedmatrix.com Nov. 7, 2009

Nov. 7, 2009

On 01:50 pm, dripton(a)ripton.net wrote: >On 2009.11.06 08:25:29 +0100, Hagen F�rstenau wrote: >> >> A switch to enable deprecation warnings would give developers a >> >> chance to see them when migrating to a new version of python. And >>it >> >> would prevent users from having to deal with them. >> > >> > PendingDeprecationWarning is silent by default and requires a switch >>to >> > be enabled. >> >>… [View More]

4 5

Summary of Python tracker Issues
by Python tracker Nov. 6, 2009

Nov. 6, 2009

ACTIVITY SUMMARY (10/30/09 - 11/06/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2479 open (+15) / 16616 closed (+15) / 19095 total (+30) Open issues with patches: 991 Average duration of open issues: 683 days. Median duration of open issues: 437 days. Open Issues Breakdown open 2444 (+15) pending 34 ( +0) Issues Created Or Reopened (31) … [View More]

1 0

2.7 Release? 2.7 == last of the 2.x line?
by ssteinerX＠gmail.com Nov. 6, 2009

Nov. 6, 2009

Not that anyone has asked yet, but here's my opinion on two issues that have been raised on the python-dev mailing list lately: +1 on 2.7 release with as much 3.0 "easy-port goo" as is practicable without delaying the product beyond the tentative schedule. Sooner would, of course, be better but I'm sure PEP 373 was produced after due consideration of all pertinent factors. +1 on 2.7 being the last of the 2.x series. Enough already! I, personally, haven't even written my first … [View More]

37 130

Refactoring installation schemes
by Tarek Ziadé Nov. 6, 2009

Nov. 6, 2009

Hello, Since the addition of PEP 370, (per-user site packages), site.py and distutils/command/install.py are *both* providing the various installation directories for Python, depending on the system and the Python version. We have also started to discuss lately in various Mailing Lists the addition of new schemes for IronPython and Jython, meaning that we might add some more in both places. I would like to suggest a simplification by adding a dedicated module to manage these installation … [View More]

9 17

No buildbot to test wide unicode?
by Amaury Forgeot d'Arc Nov. 5, 2009

Nov. 5, 2009

Hello, It seems that there is no buildbot to test a wide unicode build. On http://www.python.org/dev/buildbot/3.x/ all outputs of the "configure" steps show this message:: checking what type to use for str... unsigned short which looks like a ucs2 build to me. Since wide unicode is the standard chosen by some Linux distributions, it would make sense to have at least one buildbot running with --with-wide-unicode (3.x) or --enable-unicode=ucs4 (2.x). -- Amaury Forgeot d'Arc

4 4

nonlocal keyword in 2.x?
by Mike Krell Nov. 5, 2009

Nov. 5, 2009

Is there any possibility of backporting support for the nonlocal keyword into a 2.x release? I see it's not in 2.6, but I don't know if that was an intentional design choice or due to a lack of demand / round tuits. I'm also not sure if this would fall under the scope of the proposed moratorium on new language features (although my first impression was that it could be allowed since it already exists in python 3. One of my motivations for asking is a recent blog post by Fernando Perez of … [View More]

17 44