Mailman 3 June 2006 - Python-Dev

Stdlib Logging questions (PEP 337 SoC)
by Jim Jewett June 6, 2006

June 6, 2006

On 6/4/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: > can we please delay the import until it's actually needed? i.e., > until after some logging option is enabled? I have asked her to make this change. I don't like the extra conditional dance it causes, but I agree that not wanting to log is a valid use case. On the other hand, the one-time import cost is pretty low for a long-running process, and eventually gets paid if any other module calls logging. Would it make … [View More]

1 0

wsgiref documentation
by Doug Fort June 6, 2006

June 6, 2006

Hi, I'm going over the possible tasks for the Arlington Sprint. Documentation for wsgiref looks like somethng I could handle. My friend Joe Griffin and I did something similar for Tim Peters' FixedPoint module. Is anyone already working on this? -- Doug Fort, Consulting Programmer http://www.dougfort.com

3 3

Let's stop eating exceptions in dict lookup
by Armin Rigo June 5, 2006

June 5, 2006

Hi all, I've finally come around to writing a patch that stops dict lookup from eating all exceptions that occur during lookup, like rare bugs in user __eq__() methods. After another 2-hours long debugging session that turned out to be caused by that, I had a lot of motivation. http://python.org/sf/1497053 The patch doesn't change the PyDict_GetItem() interface, which is the historical core of the problem. It works around this issue by just moving the exception-eating bit there instead … [View More]

14 29

Mac/wastemodule build failing
by skip＠pobox.com June 5, 2006

June 5, 2006

I saw a thread here a couple days ago about a bunch of old Mac cruft going away. I recall wastemodule.c being mentioned. Now building it is failing for me (Mac OSX 10.4.6). Was it only wounded but not killed? The first couple of errors are the key I think: .../Mac/Modules/waste/wastemodule.c:19:30: error: WEObjectHandlers.h: No such file or directory .../Mac/Modules/waste/wastemodule.c:20:20: error: WETabs.h: No such file or directory Skip

2 4

patch #1454481 vs buildbot
by Andrew MacIntyre June 5, 2006

June 5, 2006

In reviewing the buildbot logs after committing this patch, I see 2 issues arising that I need advice about... 1. The Solaris build failure in thread.c has me mystified as I can't find any "_sysconf" symbol - is this in a system header? 2. I don't know what to make of the failure of test_threading on Linux, as test_thread succeeds as far as I could see. These tests succeed on my FreeBSD box and also appear to be succeeding on the Windows buildbots. Unfortunately I don't have access to … [View More]

3 4

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)
by Phillip J. Eby June 5, 2006

June 5, 2006

At 09:27 PM 6/4/2006 -0400, Jim Jewett wrote: >Jackilyn is adding logging to several stdlib modules for the Google >Summer of Code (PEP 337), and asked me to review her first few >changes. That PEP doesn't appear to have been approved, and I don't recall any discussion on Python-Dev. I also couldn't find any in the archives, except for some brief discussion regarding a *small fraction* of the huge list of modules in PEP 337. I personally don't see the value in adding this to … [View More]

2 1

Seeking Core Developers for Vancouver Python Workshop
by Paul Prescod June 5, 2006

June 5, 2006

We would like to continue the tradition of having several Python core developers at the Vancouver Python Workshop. This fun conference is small enough to be intimate but consistently attracts top-notch speakers and attendees. We would like YOU (core developer or not) on that list. Although we haven't selected all of our speakers, we've got three great keynotes lined up: Guido Van Rossum, Jim Hugunin and Ian Caven (a local Python-trepeneur). http://www.vanpyz.org/conference The conference … [View More]

1 0

Unhashable objects and __contains__()
by Collin Winter June 4, 2006

June 4, 2006

I recently submitted a patch that would optimise "in (5, 6, 7)" (ie, "in" ops on constant tuples) to "in frozenset([5, 6, 7])". Raymond Hettinger rejected (rightly) the patch since it's not semantically consistent. Quoth: >> Sorry, this enticing idea has already been explored and >> rejected. This is issue is that the transformation is not >> semanatically neutral. Currently, writing "{} in (1,2,3)" >> returns False, but after the transformation would raise an >… [View More]

3 5

Request for trackers to evaluate as SF replacement for Python development
by Brett Cannon June 4, 2006

June 4, 2006

The Python Software Foundation's Infrastructure committee has been charged with finding a new tracker system to be used by the Python development team as a replacement for SourceForge. The development team is currently unhappy with SF for several reasons which include: * Bad interface Most obvious example is the "Check to Upload" button * Lack of reliability SF has been known to go down during the day unexpectedly and stay down for hours * Lack of workflow controls For instance, … [View More]you cannot delete a category once created For these reasons and others, we are requesting the Python community help us find a new tracker to use. We are asking for test trackers to be set up to allow us to test them to see which tracker we want to move the Python development team to. This is in order to allow the Infrastructure committee to evaluate the various trackers to see which one meets our tracker needs the best. Because we are not sure exactly what are requirements for a tracker are we do not have a comprehensive requirements document. But we do have a short list of bare minimum needs: * Can import SF data http://effbot.org/zone/sandbox-sourceforge.htm contains instructions on how to access the data dump and work with the support tools (graciously developed by Fredrik Lundh) * Can export data To prevent the need to develop our own tools to get our data out of the next tracker, there must be a way to get a dump of the data (formatted or raw) that includes *all* information * Has an email interface To facilitate participation in tracker item discussions, an email interface is required to lower the barrier to add comments, files, etc. If there is a tracker you wish to propose for Python development team use, these are the steps you must follow: * Install a test tracker If you do not have the server resources needed, you may contact the Infrastructure committee at infrastructure at python.org, but our resources are limited by both machine and manpower, so *please* do what you can to use your own servers; we do not expect you to provide hosting for the final installation of the tracker for use by python-dev, though, if your tracker is chosen * Import the SF data dump http://effbot.org/zone/sandbox-sourceforge.htm * Make the Infrastructure committee members administrators of the tracker A list of the committee members can be found at http://wiki.python.org/moin/PythonSoftwareFoundationCommittees#infrastructu… * Add your tracker to the wiki page at http://wiki.python.org/moin/CallForTrackers This includes specifying the contact information for a *single* lead person to contact for any questions about the tracker; this is to keep communication simple and prevent us from having competing installations of the same tracker software * Email the Infrastructure committee that your test tracker is up and ready to be viewed We will accept new trackers for up to a maximum of two months starting 2006-06-05 (and thus ending 2006-08-07). If trackers cease to be suggested, we will close acceptance one month after the last tracker proposed (this means the maximum timeframe for all of this is three months, ending 2006-09-04). This allows us to not have this process carry on for three months if there is no need for it to thanks to people getting trackers up quickly. As the committee evaluates trackers we will add information about what we like and dislike to the http://wiki.python.org/moin/GoodTrackerFeatures wiki page so that various trackers and change their setttings and notify us of such changes. This prevents penalizing trackers that are set up quickly (which could be taken as a sign of ease of maintenance) compared to trackers that are set up later but possibly more tailored to what the Infrastructure committee discovers they want from a tracker. If you have any questions, feel free to email infrastructure at python.org . - Brett Cannon Chairman, Python Software Foundation Infrastructure committee [View Less]

1 0

Re: [Python-Dev] [Python-checkins] r46603 - python/trunk/Lib/test/test_struct.py
by Thomas Wouters June 4, 2006

June 4, 2006

On 6/4/06, Michael Hudson <mwh(a)python.net> wrote: [ For non-checkins readers: Martin Blais checked in un-unittestification of test_struct, which spawned questions form Neal and me about whether that's really the right thing to do. I also foolishly<0.5 wink> siggested that, if we switch away from unittest, we switch to py.test instead of the old unstructured tests ] "Tim Peters" <tim.peters(a)gmail.com> writes: > > unittest, and especially doctest, encourage breaking … [View More]tests into small > > units. An example of neither is test_descr.py, which can be a real > > bitch to untangle when it fails. > > Also, there is an advantage to have more structure to the tests; if > all of python's tests used unittest, my regrtest -R gimmickery would > be able to identify tests, rather than test files, that leaked and I'm > pretty sure that this would have saved me a few hours in the last > couple of years. Also, you can more easily identify particular tests > that fail intermittently. Etc. I'm not arguing against structure, just against all the unittest cumber. For example, py.test doesn't do the output-comparing, and it does require you to put tests in separate functions. However, it doesn't require (but does allow) test classes. Test-generators are generators that *return* tests, which are then run, so that you can have separate tests for runtime-calculated tasks, and yet still have them be separate tests for error reporting and such. py.test also allows tests to print during execution, and that output is kept around as debug output: it's only shown when the test fails. It also comes with a convenient command-line tool that can run directories, modules, individual tests, etc -- which, for unittest, I *always* have to copy-paste select bits out of regrtest and test_support for. My own project testing has gotten much more exhaustive since I started using py.test, it's just much, much more convenient. I'm not arguing for inclusing of py.test so much as unittest taking over most of its features (obviously not for 2.5, though.) I really don't see the point of test-classes the way we currently have them. When I look at the stdlib tests, most of the TestCases have methods that don't really need to be in a single TestCase (and I believe the 'normal' JUnit style has them as separate classes in those cases. yikes.) I don't really see the point in using all the variations of 'assert' as methods, except for 'assertRaises'. Et cetera. py.test's approach is simpler, more direct, easier to read and write, and just as powerful (and in the case of test-generators, more so.) And you can very easily emulate the unittest API with py.test ;-) Since there's time for 2.6, I'd encourage everyone to look at py.test, maybe we can just merge it with unittest ;P -- Thomas Wouters <thomas(a)python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! [View Less]

3 4