Re: [Python-Dev] [Python-checkins] r46603 - python/trunk/Lib/test/test_struct.py
On 6/4/06, Michael Hudson <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> writes:> unittest, and especially doctest, encourage breaking 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; ifall of python's tests used unittest, my regrtest -R gimmickery wouldbe 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 lastcouple of years. Also, you can more easily identify particular teststhat 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 <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46603 - python/trunk/Lib/test/test_struct.py
"Thomas Wouters" <[EMAIL PROTECTED]> writes: > On 6/4/06, Michael Hudson <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> writes: > > unittest, and especially doctest, encourage breaking 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 don't want to pull the 'do you know who I am?' routine, and I know you're addressing python-dev rather than just me, but I'm currently sitting in the same room as the guy who wrote py.test :-) I'm also not sure what point you're trying to make: I *know* py.test is better than unittest, that's not what I was saying. But unittest is better than old-skool output comparison tests. I guess you're not really replying to my mail, in fact... :) Cheers, mwh -- we need PB for C# * moshez squishes glyph glyph: squishy insane person -- from Twisted.Quotes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46603 - python/trunk/Lib/test/test_struct.py
On 6/4/06, Michael Hudson <[EMAIL PROTECTED]> wrote: "Thomas Wouters" <[EMAIL PROTECTED]> writes:> On 6/4/06, Michael Hudson <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> writes:> > unittest, and especially doctest, encourage breaking 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 don't want to pull the 'do you know who I am?' routine, and I knowyou're addressing python-dev rather than just me, but I'm currentlysitting in the same room as the guy who wrote py.test :-)I'm also not sure what point you're trying to make: I *know* py.testis better than unittest, that's not what I was saying. But unittestis better than old-skool output comparison tests.I guess you're not really replying to my mail, in fact... :) I'm sorry, I guess I was misunderstanding your mail. I thought Tim's reaction was "we want unittest because we want structure", and your reaction was "yes, we need more structure", both of which I took as "I don't really know anything about py.test" :) Since no one argued *against* structure, I'm not sure where the structure argument comes from. As for not knowing about your "involvement" with py.test, well, how could I? py.test doesn't list an 'author' anywhere I could find, the webpage just says "last edited by Holger", and the debian package came with no CREDITS file other than the 'copyright' file, which doesn't list you ;-P Credit-+=-mwh-where-credit-is-due--now-please-merge-with-unittest-already'ly y'rs,-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46603 - python/trunk/Lib/test/test_struct.py
On 6/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: On 6/4/06, Michael Hudson < [EMAIL PROTECTED]> wrote:I don't want to pull the 'do you know who I am?' routine, and I know you're addressing python-dev rather than just me, but I'm currentlysitting in the same room as the guy who wrote py.test :-)[me crediting mwh]Oh, sitting int he same *room*. Sheesh, I should really learn to read my mail. Sorry again :P -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Mac/wastemodule build failing
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac/wastemodule build failing
On 4-jun-2006, at 13:14, [EMAIL PROTECTED] wrote: 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 It that a new failure? Waste is a wrapper for the waste library, which is a 3th-party library that must be at a specific location in your tree to build correctly. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46603 - python/trunk/Lib/test/test_struct.py
On Sun, Jun 04, 2006, Thomas Wouters wrote: >On 6/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: >>On 6/4/06, Michael Hudson <[EMAIL PROTECTED]> wrote: >>> >>> I don't want to pull the 'do you know who I am?' routine, and I know >>> you're addressing python-dev rather than just me, but I'm currently >>> sitting in the same room as the guy who wrote py.test :-) >> >> [me crediting mwh] > > Oh, sitting int he same *room*. Sheesh, I should really learn to read my > mail. Sorry again :P Don't feel too sorry -- I read that as British irony for "yes, I'm the author". (As in, "I'm sitting in the same room as the author, and there's only one person in the room.") -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac/wastemodule build failing
>> 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? Ronald> It that a new failure? Yes. I svn up and rebuild at least once a week. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] patch #1454481 vs buildbot
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 either a Solaris box or a Linux box so could use some hints about resolving these. Thanks, Andrew. - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac/wastemodule build failing
On 4-jun-2006, at 15:40, [EMAIL PROTECTED] wrote: 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? Ronald> It that a new failure? Yes. I svn up and rebuild at least once a week. The failure was the result of the removeal of Mac/Wastemods, these are needed for the waste wrappers. I've just checked in a patch that removes these wrappers (revision 46644), they won't work on Intel macs, aren't used by anything in the current tree and are undocumented. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Some more comments re new uriparse module, patch 1462525
Paul Jimenez wrote: > On Friday, Jun 2, 2006, John J Lee writes: >> [Not sure whether this kind of thing is best posted as tracker comments >> (but then the tracker gets terribly long and is mailed out every time a >> change happens) or posted here. Feel free to tell me I'm posting in the >> wrong place...] > > I think this is a fine place - more googleable, still archived, etc. > >> Some comments on this patch (a new module, submitted by Paul Jimenez, >> implementing the rules set out in RFC 3986 for URI parsing, joining URI >> references with a base URI etc.) >> >> http://python.org/sf/1462525 > > Note that like many opensource authors, I wrote this to 'scratch an > itch' that I had... and am submitting it in hopes of saving someone else > somewhere some essentially identical work. I'm not married to it; I just > want something *like* it to end up in the stdlib so that I can use it. I started to write a reply to this with some comments on the API (including the internal subclassing API), but ended up with so many different suggestions it was easier to just post a variant of the module. I called it "urischemes" and posted it on SF: http://python.org/sf/1500504 It takes more advantage of the strict hierarchy defined in RFC 3986 by always treating parsed URI's as 5-tuples, and the authority component as a 4-tuple. A parser is allowed to return any object it likes for the path, query or fragment components, so long as invoked str() on the result gives an appropriate string for use by make_uri. Additionally, since the semantics won't be the same as urlparse anyway, I haven't been as worried about keeping the APIs identical (although they're still similar). In various places, it also makes more use of keyword arguments and dictionaries to specify defaults values, rather than relying on tuples padded with lots of Nones. There's more in the tracker item about the API and implementation differences. They're all about improving maintainability and extensibility rather than providing any additional functionality. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch #1454481 vs buildbot
[Andrew MacIntyre]
> 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?
The patch's
#if THREAD_STACK_MIN < PTHREAD_STACK_MIN
assumes that the expansion of PTHREAD_STACK_MIN acts like a
compile-time constant expression, but there's no such guarantee.
http://cvs.opensolaris.org/source/xref/on/usr/src/head/limits.h
shows that, on one version of Solaris, it's actually defined via
#define PTHREAD_STACK_MIN ((size_t)_sysconf(_SC_THREAD_STACK_MIN))
That has a runtime value, but not a useful compile-time value. The
only useful thing you can do with it in an #if expression is
defined(PTHREAD_STACK_MIN).
> 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.
Not all pthreads-using builds fail, and not all failing pthreads-using
builds fail in the same way. Welcome to pthreads on Linux ;-)
BTW, this sucks:
test_thread
/home/buildbot/Buildbot/trunk.baxter-ubuntu/build/Lib/test/test_thread.py:138:
RuntimeWarning: thread stack size of 0x1000 bytes not supported
thread.stack_size(tss)
That's from a successful run. RuntimeWarning really doesn't make
sense for a failing operation. This should raise an exception
(xyzError, not xyzWarning), or a failing stack_size() should return an
error value after ensuring the original stack size is still in effect.
> Unfortunately I don't have access to either a Solaris box or a Linux box
> so could use some hints about resolving these.
As above, they don't always fail in the same way across boxes. The
most popular failure mode appears to be:
ERROR: test_various_ops_large_stack (test.test_threading.ThreadTests)
--
Traceback (most recent call last):
File
"/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/test/test_threading.py",
line 101, in test_various_ops_large_stack
self.test_various_ops()
File
"/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/test/test_threading.py",
line 77, in test_various_ops
t.start()
File
"/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/threading.py",
line 434, in start
_start_new_thread(self.__bootstrap, ())
error: can't start new thread
While I don't know, best guess is that the system "ulimit -s" is set
to 8MB, so it's not actually possible to get a 16MB stack (as
test_various_ops_large_stack() asks for), and this error goes
undetected at the test's
threading.stack_size(0x100)
call "for some reason". Or maybe it is, but the RuntimeWarning got
lost -- if this were an exception instead, it would be easier to
reason about, and test_various_ops_large_stack() could disable itself
gracefully (by catching the exception and giving up) if the platform
didn't allow a 16MB stack ...
Ah, _pythread_pthread_set_stacksize doesn't do anything to verify that
the requested stack size is actually usable (just ensures that it's
less than THREAD_STACK_MIN). pthread_attr_setstacksize() isn't
attempted until PyThread_start_new_thread() in thread_pthread.h:
#if defined(THREAD_STACK_SIZE)
tss = (_pythread_stacksize != 0) ? _pythread_stacksize
: THREAD_STACK_SIZE;
if (tss != 0) {
if (pthread_attr_setstacksize(&attrs, tss) != 0) {
pthread_attr_destroy(&attrs);
return -1;
}
}
#endif
If PyThread_start_new_thread() fails in any way
(like,pthread_attr_setstacksize() failing), ""can't start new thread"
is the error we see.
The difference between test_thread and test_threading here is that
only test_threading asks for a 16MB stack; test_thread doesn't ask for
a stack larger than 4MB.
Until all this gets resolved, I strongly suggest reverting this patch
(if you don't, someone else will ...) and hammering out the problems
on a new branch instead. See python-dev email from yesterday for how
to force a buildbot slave to build a branch.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch #1454481 vs buildbot
Tim> Until all this gets resolved, I strongly suggest reverting this Tim> patch ... So I won't check in changes to suppress compilation warnings on my Mac. Andrew, look in your mail for a patch file. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Request for trackers to evaluate as SF replacement for Python development
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, you cannot delete a category once createdFor 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#infrastructure-committee-ic * 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 viewedWe 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unhashable objects and __contains__()
On 6/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 6/3/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > > Collin Winter wrote: > > > Idea: what if Python's -O option caused PySequence_Contains() to > > > convert all errors into False return values? > > > > It would certainly give me an uneasy feeling if a command-line switch > > caused such a change in semantics. > > I missed that. Collin must be suffering from a heat stroke. :-) I don't think Munich gets hot enough for heat stroke ; ) The more likely culprit is a lack of coffee this morning and a bit too much weissbier last night. Consider the idea eagerly withdrawn. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unhashable objects and __contains__()
Collin Winter wrote: > On 6/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On 6/3/06, Georg Brandl <[EMAIL PROTECTED]> wrote: >> > Collin Winter wrote: >> > > Idea: what if Python's -O option caused PySequence_Contains() to >> > > convert all errors into False return values? >> > >> > It would certainly give me an uneasy feeling if a command-line switch >> > caused such a change in semantics. >> >> I missed that. Collin must be suffering from a heat stroke. :-) > > I don't think Munich gets hot enough for heat stroke ; ) I can confirm that, unfortunately. The best thing you can say about our weather at the moment is that the winter is relatively mild :( > The more likely culprit is a lack of coffee this morning and a bit > too much weissbier last night. I'd blame it on the coffee. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Seeking Core Developers for Vancouver Python Workshop
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/conferenceThe conference will be very affordable, with cut-rate registration fees for speakers, prices in Canadian dollars and carefully negotiated hotel rates. Please contact me with any questions or proceed directly to the talk submission form! Paul Prescod ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Stdlib Logging questions (PEP 337 SoC)
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.
There were a few comments that I felt I should double-check with
Python-dev first, in case my own intuition is wrong.
For reference, she is adding the following prologue to several modules:
import logging
_log = logging.getLogger('py.NAME')
where NAME is the module name
(1) Should we ask Vinay Sajip to add a convenience function (for
getting the stdlib logger) to the logging module itself?
It seems like it might be overkill, amd it wouldn't save even a single line.
On the other hand, I wonder if we will eventually end up wanting a
common choke point for hooks. PEP 337 did not recommend any such
function, and recommended setting the handlers and level for py.* as
sufficient control.
So I'm inclined to say "no changes to the logging package itself".
(2) Should NAME be module.__name__?
Note that this means the log messages would be different when the
module is run as a script (and the name is therefore __main__).
I'm not thrilled with repeating the module name as a string, but I
think that may be the lesser of evils.
(3) Should she put out a message when a (now logged) module is
loaded? If so, at what level?
I'm leaning towards
_log.debug("Stdlib NAME loaded as ", __name__)
(4) Should she add (other) debugging information that is not already present?
I think that "if __debug__: print ..." or "if debuglevel>0:
sys.stdout.write..." should be changed, and things like set_debuglevel
should be translated to calls to change the level of the appropriate
logger.
What about print lines that are currently commented out? Should these
be displayed at debug level? (I think so.)
What about useful information that isn't currently displayed? For
instance, the asyncore module is careful to reuse a global mapping if
it already exists (presumably from a reload), but that seems rare
enough that it should be worth at least an info message.
What about normal config info, such as the typical case of creating an
empty mapping? In Java, I would expect a CONFIG message either way.
In python, that seems like too much of a change, but ... at debug
level ... maybe not doing it is just a bad habit.
Unless convinced otherwise, I'll ask her to use debug for commented
out lines that were still important enough to leave in the code, info
message for unexpected choices, and not to bother with logging "yup,
did the normal thing"
(5) Should she clean up other issues when touching a module?
In general, stdlib code isn't updated just for style reasons, unless
there is a deprecation -- but in these cases, the module is already
changing slightly.
My inclination would be that she doesn't have to fix everything, but
should generally do so when either it is "easy" or the old code is
arguably a bug (such as bare excepts). (And "easy" might change as
the summer wears on.)
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)
Jim> (1) Should we ask Vinay Sajip to add a convenience function (for Jim> getting the stdlib logger) to the logging module itself? -1. Jim> (2) Should NAME be module.__name__? Seems reasonable. Jim> (3) Should she put out a message when a (now logged) module is Jim> loaded? If so, at what level? -1. I don't think it buys you anything. If you need it, the -v command line flag should be sufficient. Jim> (4) Should she add (other) debugging information that is not Jim> already present? I'd say "no". Behavior changes should be kept to a bare minimum. Jim> (5) Should she clean up other issues when touching a module? I suggest they be submitted as separate patches so as not to confuse distinct issues (say, if one part needs to be retracted). Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)
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 anything but modules
that already do some kind of logging. And even some of the modules listed
in the PEP that do some kind of output, I don't really see what the use
case for using the logging module is. (Why does timeit need a logger, for
example?)
>There were a few comments that I felt I should double-check with
>Python-dev first, in case my own intuition is wrong.
>
>For reference, she is adding the following prologue to several modules:
>
> import logging
> _log = logging.getLogger('py.NAME')
>
>where NAME is the module name
If this *has* to be added to the modules that don't currently do any
logging, can we please delay the import until it's actually needed? i.e.,
until after some logging option is enabled? I don't really like the
logging module myself and would rather it were not imported as a side
effect of merely using shlex or pkgutil!
>(5) Should she clean up other issues when touching a module?
>
>In general, stdlib code isn't updated just for style reasons,
Which is a good enough reason, IMO, to vote -1 on the PEP if it's not pared
back to reflect *only* modules with a valid use case for logging.
I think it would be a good idea to revisit the module list. I can see a
reasonable case for the BaseHTTP stuff and asyncore needing a logging
framework, if you plan to make them part of some larger framework -- the
configurability would be a plus, even if I personally don't like the way
the logging module does configuration. But most of the other modules, I
just don't see why something more complex than prints are desirable. As of
Python 2.5, if you want stdout or stderr temporarily redirected, it's easy
enough to wrap your calls in a with: block.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
