Mailman 3 October 2005 - pytest-dev

[py-dev] Hi! And py.log :-)
by François Pinard Jan. 21, 2006

Jan. 21, 2006

Hi, people. I just subscribed to py-dev@codespeak. The page at: http://agiletesting.blogspot.com/2005/06/keyword-based-logging-with-py-libr… says: If you think you can use the keyword-based approach to logging in your own application code, or if you have a use case that you would like to see implemented via py.log, or if you have any suggestions at all, please leave a comment here of send email to py-dev at codespeak dot net. So here! :-) I'm preparing to clean up a big Python application which, among other things, (ab)uses the concept of logging, with many complex, over-loaded logging routines. My guess is that cleaning this single aspect, if done properly, would significantly reduce the amount of noise in the source code of this application, and so, somehow increase its legibility. I'm always starving for clean, simple design, and this is how I got interested in `py.log'. Am I welcome at discussing logging issues here, in the context of `py.log', as they will pop up in our adventure? -- François Pinard http://pinard.progiciels-bpi.ca

6 11

[py-dev] py.log suggestion
by François Pinard Nov. 12, 2005

Nov. 12, 2005

Hi, people. I wrote to this list, a little while ago, about using py.log in some big Python project I should seriously clean up, and which currently abuses of various logging mechanisms. I thought this job would induce me in using quite a flurry of py.log producers. Instead, for the past weeks, I was more active at aggressively forever _removing_ amounts of logging calls. A lot still remain, for which py.log is going to be useful. Today, I saw a situation of logging made in context of tracing the hearth of one of the evaluation engines. When such logging/tracing is active, the application is going to be applied to a toy subset of the real input. Otherwise, logging would be triggered millions of times. The problem is that log messages themselves require a fair amount of extra-computation that would better be spared when tracing is not active (which is most of the time). My suggestion, here, is that producers, besides their ``__call__`` method, could also offer a ``__nonzero__`` method that would return False when the consumer that would apply is None. So, one could write something like: if trace.dossier: diagnostic = prepare_diagnostic_information() trace.dossier(diagnostic) It looks clean and lean to me to use the producer for the test as well as for the call. Do you share this opinion? -- François Pinard http://pinard.progiciels-bpi.ca

3 8

[py-dev] Holger and RFC 2646
by François Pinard Oct. 30, 2005

Oct. 30, 2005

Hi, gang. This is a bit off-topic. In a recent message, I remarked about those spurious spaces at end of lines in messages from Holger, and understood since then those spaces come from RFC 2646 and "format=flowed" specification. Curious, I looked more closely in my folders of saved articles, and found out that "f=f" is not that uncommon. It is just that my usual correspondents do not use it, making Holger messages appear unusual. So, sorry for my noise! -- François Pinard http://pinard.progiciels-bpi.ca

2 2

[py-dev] Thanks a lot for py.test!
by François Pinard Oct. 28, 2005

Oct. 28, 2005

Hi, people. I just wanted to share my enthusiasm for py.test. In a relatively short amount of time, I wrote a lot of tests (1122 so far) for the big project keeping me busy in these days. With careful thinking and much using generators, it is very easy to lie tests down cleanly and quickly, in a progressive way, just as a way to crystallise my understanding of the project as it develops, making it more solid. For a few cases, test functions are more convenient and leaner than test methods, while in other cases, it is more natural grouping tests within test classes. Whenever needed, setup and teardown helpers are sometimes better written at module level, sometimes at class level (I had not use for method level so far). As I test on different machines and locations, the disabling feature is rather useful to cope with various limitations, like firewalls and such. When I have some need to express, py.test offers a nice, simple, clean, fast way. It's pure pleasure! :-) And I did not even study nor use the parts of the documentation about implementation or customization -- maybe I'm not sophisticated enough yet for needing them :-) -- but in any case, it leaves me with the good feeling that there is loose power available if I ever need more. All in all, it seems that one can do lots, by using nothing more than the simpler parts of py.test. It's much comforting. Thanks, gang! -- François Pinard http://pinard.progiciels-bpi.ca

2 4

[py-dev] py.test tracing within generators
by François Pinard Oct. 22, 2005

Oct. 22, 2005

Hi, people. When a test is launched and fails, after the effect of a generative test, it would be useful if the stack trace somehow included an indication about which line was active within the generator. Either the ``yield`` line contents, or its location within the generator, may give good clues about what the real test is, or is about. For now, I yield to the real test function strings containing Python expressions, to be later eval'ed within the real test function, and also used as second argument to ``assert``. In this way, py.test displays the information I need in the stack trace. But this is a bit of a stunt, which would be nicer if avoided. We all know how easy it is, for a user like me, making such suggestions, while they are likely difficult to implement. So, I well understand that this particular suggestion may not be reasonable. Yet, with some luck, there might be tricks you know and I do not even suspect! :-) -- François Pinard http://pinard.progiciels-bpi.ca

2 1

[py-dev] Praise heaped on PyPy
by Grig Gheorghiu Oct. 16, 2005

Oct. 16, 2005

I'm sure you guys have all seen this by now, but just in case you haven't: http://dirtsimple.org/2005/10/children-of-lesser-python.html Grig

1 0

[py-dev] Convention for TDD
by Ian Bicking Oct. 11, 2005

Oct. 11, 2005

Is there any convention people are using with py.test for test-drive-development tests that still fail? Like a convention for saying I-fail-but-don't-worry; some combination of keywords and disabling variables so it can only be run explicitly? Ian

5 5