From pinard at iro.umontreal.ca Sun Oct 2 21:58:45 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Sun, 2 Oct 2005 15:58:45 -0400 Subject: [py-dev] Hi! And py.log :-) Message-ID: <20051002195845.GA12570@phenix.progiciels-bpi.ca> Hi, people. I just subscribed to py-dev at codespeak. The page at: http://agiletesting.blogspot.com/2005/06/keyword-based-logging-with-py-library.html 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 From hpk at trillke.net Sun Oct 2 22:01:42 2005 From: hpk at trillke.net (holger krekel) Date: Sun, 2 Oct 2005 22:01:42 +0200 Subject: [py-dev] Hi! And py.log :-) In-Reply-To: <20051002195845.GA12570@phenix.progiciels-bpi.ca> References: <20051002195845.GA12570@phenix.progiciels-bpi.ca> Message-ID: <20051002200142.GS4208@solar.trillke.net> Hi Francois! On Sun, Oct 02, 2005 at 15:58 -0400, Fran?ois Pinard wrote: > Hi, people. I just subscribed to py-dev at codespeak. The page at: > > http://agiletesting.blogspot.com/2005/06/keyword-based-logging-with-py-library.html > > 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? Yes, it is. Actually the logging API is still quite experimental so your feedback is most welcome. In fact, there are two logging APIs. The current approach has a global dispatching mechanism that maps produced messages to consumers. Grig has described that in his blog. The new experimental approach is less dynamic and has a single entry "py.log.get(loggername, chan1=consumer, ...)" but it is not documented, unfortunately. I guess i need to make my mind up about the right approach. But for the time being, i'd suggest just forgetting about py.log.get() and sticking to the more documented approach. cheers, holger From pinard at iro.umontreal.ca Sun Oct 2 23:07:46 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Sun, 2 Oct 2005 17:07:46 -0400 Subject: [py-dev] Hi! And py.log :-) In-Reply-To: <20051002200142.GS4208@solar.trillke.net> References: <20051002195845.GA12570@phenix.progiciels-bpi.ca> <20051002200142.GS4208@solar.trillke.net> Message-ID: <20051002210746.GA13685@phenix.progiciels-bpi.ca> [holger krekel] > Hi Francois! Hi Holger, and thanks for replying! > Actually the logging API is still quite experimental so your feedback > is most welcome. You did open the door! :-) I fetched py-dev at codespeak.net archives a few hours ago, but it will take some time before I become acquainted with them, so I may raise issues which have already been discussed, I do not know yet. > [...] But for the time being, i'd suggest just forgetting about > py.log.get() and sticking to the more documented approach. OK. In any case, the code base for our big application is likely to be boiling at least for the next six months or so, so changes are always possible on our side for quite a while, without being hurtful. Let me start the discussion on the following issue. It is a common and useful idiom, where I work most of the time, to pass a ``write`` argument to various functions, letting the caller decide what ``write`` will do in any particular case. It could be an opened file, the input side of a service process, the ``append`` method of a list, or God knows what else. It would be convenient being able to merely pass a logger for that ``write`` argument, hoping this would yield a sensible behaviour. This comes with problems, however. Currently, py.log and the standard logging module both provide a newline after the text to be logged. If I provide a newline at the end of a text given to a py.log logger, this will create a spurious white line. Whether a logger should remove trailing newlines or not, is debatable. For one, I would be willing and ready to always provide the trailing newline in my calls, given I expect the logger to add none, so logging functions and ``write`` functions are more fully interchangeable. However, tradition is that logging functions turn incomplete lines into complete lines. I do not know where lies the greater wisdom... Another point, which is pretty factual in our code base, is that the application often logs multi-line texts, which are then (of course) displayed on many lines. I really dislike runs of stars or hyphens for creating visual blocks out of such log messages. Currently, py.log merely transmits embedded newlines as is, so the output is a bit unclear about if a line is part of the log message, or not. A multi-line logged message might neatly insert a white margin to the left of all lines except the first, with the margin length being equal to the size of the prefix (shown between square brackets) found on the first line. This (different prefix, different margins) would be more legible, I think, than a fixed margin size -- yet we might theoretically imagine bad effects from very long prefixes, all unlikely that they can be. -- Fran?ois Pinard http://pinard.progiciels-bpi.ca From hpk at trillke.net Mon Oct 3 09:37:53 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 3 Oct 2005 09:37:53 +0200 Subject: [py-dev] Hi! And py.log :-) In-Reply-To: <20051002210746.GA13685@phenix.progiciels-bpi.ca> References: <20051002195845.GA12570@phenix.progiciels-bpi.ca> <20051002200142.GS4208@solar.trillke.net> <20051002210746.GA13685@phenix.progiciels-bpi.ca> Message-ID: <20051003073753.GT4208@solar.trillke.net> Hi, [Francois Pinard] > [holger krekel] > > Actually the logging API is still quite experimental so your feedback > > is most welcome. > > You did open the door! :-) > > I fetched py-dev at codespeak.net archives a few hours ago, but it will > take some time before I become acquainted with them, so I may raise > issues which have already been discussed, I do not know yet. Thanks for taking care. > > [...] But for the time being, i'd suggest just forgetting about > > py.log.get() and sticking to the more documented approach. > > OK. In any case, the code base for our big application is likely to be > boiling at least for the next six months or so, so changes are always > possible on our side for quite a while, without being hurtful. Good. There also is a growing number of pypy-usages of the log functionality but doing changes there should not be a big problem either. > Let me start the discussion on the following issue. > > It is a common and useful idiom, where I work most of the time, to pass > a ``write`` argument to various functions, letting the caller decide > what ``write`` will do in any particular case. It could be an opened > file, the input side of a service process, the ``append`` method of a > list, or God knows what else. It would be convenient being able to > merely pass a logger for that ``write`` argument, hoping this would > yield a sensible behaviour. This comes with problems, however. I think it's a very valid concern. So there should be some code path that makes this easy. > Currently, py.log and the standard logging module both provide a newline > after the text to be logged. If I provide a newline at the end of a > text given to a py.log logger, this will create a spurious white line. > Whether a logger should remove trailing newlines or not, is debatable. > For one, I would be willing and ready to always provide the trailing > newline in my calls, given I expect the logger to add none, so logging > functions and ``write`` functions are more fully interchangeable. > However, tradition is that logging functions turn incomplete lines into > complete lines. I do not know where lies the greater wisdom... Maybe we could add e.g. "autocr=True|False" somewhere to make this configurable. > Another point, which is pretty factual in our code base, is that the > application often logs multi-line texts, which are then (of course) > displayed on many lines. I really dislike runs of stars or hyphens for > creating visual blocks out of such log messages. I share that dislike. > Currently, py.log merely transmits embedded newlines as is, > so the output is a bit unclear about if a line is part of > the log message, or not. A multi-line logged message might > neatly insert a white margin to the left of all lines except > the first, with the margin length being equal to the size of > the prefix (shown between square brackets) found on the > first line. This (different prefix, different margins) > would be more legible, I think, than a fixed margin size -- > yet we might theoretically imagine bad effects from very > long prefixes, all unlikely that they can be. The suggestion makes sense (inserting " " * len(prefix) after newlines in messages). Actually I would like to sit together with you for some hours sorting out usages/scenarios and designing the API accordingly. I also have a couple of more ideas of how py.log should fit with other usages like sending things remotely over py.execnet channels. Just to mention it already: i am thinking of doing a py lib hacking/sprinting session around Pycon US 2006. For the time being, I'd suggest that you get commit rights and we work commonly on some (non-main-page linked for now) feature descriptions/api scenarios in py/documentation/log.txt to sort out the goals. Implementing it is less of a deal, i think and we can first do it by introducing py.log2 until the API is settled/tested by real code. If you agree just send me your account name/ssh-key. Maybe Grig is also interested in participating in that effort. cheers, holger From grig at gheorghiu.net Mon Oct 3 15:38:16 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Mon, 3 Oct 2005 06:38:16 -0700 (PDT) Subject: [py-dev] Hi! And py.log :-) In-Reply-To: <20051003073753.GT4208@solar.trillke.net> Message-ID: <20051003133816.5161.qmail@web54502.mail.yahoo.com> Hi, Francois and Holger (have been pretty busy during the weekend, so I'm only now reading this thread...) --- holger krekel wrote: > Hi, > > [Francois Pinard] > > [holger krekel] > > > Actually the logging API is still quite experimental so your > feedback > > > is most welcome. > > > > You did open the door! :-) > > > > I fetched py-dev at codespeak.net archives a few hours ago, but it > will > > take some time before I become acquainted with them, so I may raise > > issues which have already been discussed, I do not know yet. > > Thanks for taking care. > > > > [...] But for the time being, i'd suggest just forgetting about > > > py.log.get() and sticking to the more documented approach. > > > > OK. In any case, the code base for our big application is likely > to be > > boiling at least for the next six months or so, so changes are > always > > possible on our side for quite a while, without being hurtful. > > Good. There also is a growing number of pypy-usages of the log > functionality but doing changes there should not be a big problem > either. > > > Let me start the discussion on the following issue. > > > > It is a common and useful idiom, where I work most of the time, to > pass > > a ``write`` argument to various functions, letting the caller > decide > > what ``write`` will do in any particular case. It could be an > opened > > file, the input side of a service process, the ``append`` method of > a > > list, or God knows what else. It would be convenient being able to > > merely pass a logger for that ``write`` argument, hoping this would > > yield a sensible behaviour. This comes with problems, however. > > I think it's a very valid concern. So there should be some code path > > that makes this easy. > > > Currently, py.log and the standard logging module both provide a > newline > > after the text to be logged. If I provide a newline at the end of > a > > text given to a py.log logger, this will create a spurious white > line. > > Whether a logger should remove trailing newlines or not, is > debatable. > > For one, I would be willing and ready to always provide the > trailing > > newline in my calls, given I expect the logger to add none, so > logging > > functions and ``write`` functions are more fully interchangeable. > > However, tradition is that logging functions turn incomplete lines > into > > complete lines. I do not know where lies the greater wisdom... > > Maybe we could add e.g. "autocr=True|False" somewhere to make > this configurable. This should indeed be pretty easy to implement. > > > Another point, which is pretty factual in our code base, is that > the > > application often logs multi-line texts, which are then (of course) > > displayed on many lines. I really dislike runs of stars or hyphens > for > > creating visual blocks out of such log messages. > > I share that dislike. > > > Currently, py.log merely transmits embedded newlines as is, > > so the output is a bit unclear about if a line is part of > > the log message, or not. A multi-line logged message might > > neatly insert a white margin to the left of all lines except > > the first, with the margin length being equal to the size of > > the prefix (shown between square brackets) found on the > > first line. This (different prefix, different margins) > > would be more legible, I think, than a fixed margin size -- > > yet we might theoretically imagine bad effects from very > > long prefixes, all unlikely that they can be. > > The suggestion makes sense (inserting " " * len(prefix) > after newlines in messages). I agree. > > Actually I would like to sit together with you for some hours > sorting out usages/scenarios and designing the API accordingly. > I also have a couple of more ideas of how py.log should fit > with other usages like sending things remotely over py.execnet > channels. I think the more usage scenarios we have, the better the py.log API will get. Maybe we can chat on IRC one day. > > Just to mention it already: i am thinking of doing a py lib > hacking/sprinting session around Pycon US 2006. > > For the time being, I'd suggest that you get commit rights > and we work commonly on some (non-main-page linked for now) > feature descriptions/api scenarios in py/documentation/log.txt > to sort out the goals. Implementing it is less of a deal, > i think and we can first do it by introducing py.log2 until > the API is settled/tested by real code. If you agree just > send me your account name/ssh-key. Maybe Grig is also > interested in participating in that effort. I am very interested in participating. Thanks for the interest, Francois, we need more people like you who want to use py.log in their projects :-) Grig From pobrien at orbtech.com Mon Oct 3 16:13:07 2005 From: pobrien at orbtech.com (Patrick K. O'Brien) Date: Mon, 03 Oct 2005 09:13:07 -0500 Subject: [py-dev] Hi! And py.log :-) In-Reply-To: <20051003133816.5161.qmail@web54502.mail.yahoo.com> References: <20051003133816.5161.qmail@web54502.mail.yahoo.com> Message-ID: <43413C73.3010701@orbtech.com> Grig Gheorghiu wrote: > I am very interested in participating. Thanks for the interest, > Francois, we need more people like you who want to use py.log in their > projects :-) Some Schevo folks might be interested in participating as well... We need a good logging mechanism for Schevo, but also need to minimize our dependencies and make sure anything we do use will work well with setuptools and eggs. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Pypersyst http://www.pypersyst.org From grig at gheorghiu.net Mon Oct 3 16:20:58 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Mon, 3 Oct 2005 07:20:58 -0700 (PDT) Subject: [py-dev] Hi! And py.log :-) In-Reply-To: <43413C73.3010701@orbtech.com> Message-ID: <20051003142058.65227.qmail@web54507.mail.yahoo.com> --- "Patrick K. O'Brien" wrote: > Grig Gheorghiu wrote: > > I am very interested in participating. Thanks for the interest, > > Francois, we need more people like you who want to use py.log in > their > > projects :-) > > Some Schevo folks might be interested in participating as well... > > We need a good logging mechanism for Schevo, but also need to > minimize > our dependencies and make sure anything we do use will work well with > setuptools and eggs. That's great to hear. Maybe Holger can coordinate some group discussions. We can also start by people writing down their wishlist for py.log and then prioritize the features we want to implement. Grig From hpk at trillke.net Mon Oct 3 16:26:32 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 3 Oct 2005 16:26:32 +0200 Subject: [py-dev] Hi! And py.log :-) In-Reply-To: <20051003142058.65227.qmail@web54507.mail.yahoo.com> References: <43413C73.3010701@orbtech.com> <20051003142058.65227.qmail@web54507.mail.yahoo.com> Message-ID: <20051003142632.GE4208@solar.trillke.net> On Mon, Oct 03, 2005 at 07:20 -0700, Grig Gheorghiu wrote: > --- "Patrick K. O'Brien" wrote: > > > Grig Gheorghiu wrote: > > > I am very interested in participating. Thanks for the interest, > > > Francois, we need more people like you who want to use py.log in > > their > > > projects :-) > > > > Some Schevo folks might be interested in participating as well... > > > > We need a good logging mechanism for Schevo, but also need to > > minimize > > our dependencies and make sure anything we do use will work well with > > setuptools and eggs. > > That's great to hear. Maybe Holger can coordinate some group > discussions. We can also start by people writing down their wishlist > for py.log and then prioritize the features we want to implement. Good idea. I can try that but i am leaving for Paris (for a PyPy sprint plus other meetings) tomorrow and will be on the road until 5th November. So it's not yet clear for me when i would get to it. OTOH, there is no big hurry so i hope i can work on logging - among other things - from my work-holiday flat in Marroco second half October :) This should not keep us from writing down thoughts and ideas sooner already. cheers, holger From briandorsey at gmail.com Mon Oct 3 22:39:06 2005 From: briandorsey at gmail.com (Brian Dorsey) Date: Mon, 3 Oct 2005 13:39:06 -0700 Subject: [py-dev] Hi! And py.log :-) In-Reply-To: <20051003073753.GT4208@solar.trillke.net> References: <20051002195845.GA12570@phenix.progiciels-bpi.ca> <20051002200142.GS4208@solar.trillke.net> <20051002210746.GA13685@phenix.progiciels-bpi.ca> <20051003073753.GT4208@solar.trillke.net> Message-ID: <66e877b70510031339n6449adc3t@mail.gmail.com> On 03/10/05, holger krekel wrote: > Just to mention it already: i am thinking of doing a py lib > hacking/sprinting session around Pycon US 2006. That would be fabulous. I'll likely be able to go to PyCon again, and hacking on py lib would be a great sprint. ;) Take care, -Brian From pinard at iro.umontreal.ca Tue Oct 4 00:51:16 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Mon, 3 Oct 2005 18:51:16 -0400 Subject: [py-dev] Hi! And py.log :-) In-Reply-To: <20051003073753.GT4208@solar.trillke.net> References: <20051002195845.GA12570@phenix.progiciels-bpi.ca> <20051002200142.GS4208@solar.trillke.net> <20051002210746.GA13685@phenix.progiciels-bpi.ca> <20051003073753.GT4208@solar.trillke.net> Message-ID: <20051003225116.GB22429@alcyon.progiciels-bpi.ca> [holger krekel] > Actually I would like to sit together with you for some hours sorting > out usages/scenarios and designing the API accordingly. I spent the afternoon with the application designer, staring at the logging calls within only one of our numerous Python modules. It looks like the mere inventory of logging cases is going to be a big job. So, I'm not ready to give you a complete picture of the problem here. On the other hand, even an incomplete picture could be useful to shake a few ideas, if it does not cast decisions in stone prematurely. > Just to mention it already: i am thinking of doing a py lib > hacking/sprinting session around Pycon US 2006. I'm of course willing to sit with you, and anybody else interested. Presumably each of us at our terminal, as I'm not much of a traveller, and I also guess you do not live in Montreal or suburbs :-). You're thinking of IRC, probably? > we work commonly on some (non-main-page linked for now) feature > descriptions/api scenarios in py/documentation/log.txt to sort out the > goals. Sounds good. > Implementing it is less of a deal, i think and we can first do it by > introducing py.log2 until the API is settled/tested by real code. Besides, py.log is currently not such a big thing. It likely have enough flexibility already that I can make things work for us here, before they really get available in the mainstream. I'm ready to adapt. > Maybe Grig is also interested in participating in that effort. I surely thank him for having provided a visible pointer to py.log! The fun thing is that we started using py.test in that project not so long ago (the administrators accepted that I use experimental software), so now pushing for py.log was much easier, given the proximity! :-) -- Fran?ois Pinard http://pinard.progiciels-bpi.ca From ianb at colorstudy.com Mon Oct 10 05:13:07 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Sun, 09 Oct 2005 22:13:07 -0500 Subject: [py-dev] Convention for TDD Message-ID: <4349DC43.3060806@colorstudy.com> 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 From dstanek at dstanek.com Mon Oct 10 14:24:29 2005 From: dstanek at dstanek.com (David Stanek) Date: Mon, 10 Oct 2005 08:24:29 -0400 Subject: [py-dev] Convention for TDD In-Reply-To: <4349DC43.3060806@colorstudy.com> References: <4349DC43.3060806@colorstudy.com> Message-ID: <20051010122429.GA7436@goliath.hsd1.oh.comcast.net> On Sun, Oct 09, 2005 at 10:13:07PM -0500, Ian Bicking wrote: > 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? What exactly are you trying to do? When I practice TDD I like when the tests fail so I know what I need to be working on. Once I get all of the tests to pass I add a couple more knowing that the code to support them is not there and the test will fail. David -- GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ianb at colorstudy.com Mon Oct 10 17:52:33 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 10 Oct 2005 10:52:33 -0500 Subject: [py-dev] Convention for TDD In-Reply-To: <20051010122429.GA7436@goliath.hsd1.oh.comcast.net> References: <4349DC43.3060806@colorstudy.com> <20051010122429.GA7436@goliath.hsd1.oh.comcast.net> Message-ID: <434A8E41.5000702@colorstudy.com> David Stanek wrote: > On Sun, Oct 09, 2005 at 10:13:07PM -0500, Ian Bicking wrote: > >>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? > > > What exactly are you trying to do? When I practice TDD I like when > the tests fail so I know what I need to be working on. Once I get > all of the tests to pass I add a couple more knowing that the code > to support them is not there and the test will fail. I'm writing some experimental code, and I want to check it in before it is finished. But I want other people to know that it's okay that the tests fail (while I also want them to be able to see the code's progress). -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From hpk at trillke.net Mon Oct 10 19:01:54 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 10 Oct 2005 19:01:54 +0200 Subject: [py-dev] Convention for TDD In-Reply-To: <434A8E41.5000702@colorstudy.com> References: <4349DC43.3060806@colorstudy.com> <20051010122429.GA7436@goliath.hsd1.oh.comcast.net> <434A8E41.5000702@colorstudy.com> Message-ID: <20051010170154.GA23762@solar.trillke.net> On Mon, Oct 10, 2005 at 10:52 -0500, Ian Bicking wrote: > David Stanek wrote: > >On Sun, Oct 09, 2005 at 10:13:07PM -0500, Ian Bicking wrote: > > > >>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? > > > > > >What exactly are you trying to do? When I practice TDD I like when > >the tests fail so I know what I need to be working on. Once I get > >all of the tests to pass I add a couple more knowing that the code > >to support them is not there and the test will fail. > > I'm writing some experimental code, and I want to check it in before it > is finished. But I want other people to know that it's okay that the > tests fail (while I also want them to be able to see the code's progress). there is no single convention i know off. I guess that DONT_TEST_test_whatever is the one i have seen most often. holger From briandorsey at gmail.com Tue Oct 11 07:49:27 2005 From: briandorsey at gmail.com (Brian Dorsey) Date: Mon, 10 Oct 2005 22:49:27 -0700 Subject: [py-dev] Convention for TDD In-Reply-To: <20051010170154.GA23762@solar.trillke.net> References: <4349DC43.3060806@colorstudy.com> <20051010122429.GA7436@goliath.hsd1.oh.comcast.net> <434A8E41.5000702@colorstudy.com> <20051010170154.GA23762@solar.trillke.net> Message-ID: <66e877b70510102249k3dc2338ct@mail.gmail.com> On 10/10/05, holger krekel wrote: > there is no single convention i know off. I guess that > > DONT_TEST_test_whatever > > is the one i have seen most often. Right after I leared about the disabled attribute on classes ( http://codespeak.net/py/current/doc/test.html#disabling-a-test-class) I tried to use it in the body of a test function. I don't know why I thought that would work, but I did. ;) Now, I change the names to disabled_test_whatever(). Take care, -Brian From ischenko at gmail.com Tue Oct 11 07:54:01 2005 From: ischenko at gmail.com (Max Ischenko) Date: Tue, 11 Oct 2005 08:54:01 +0300 Subject: [py-dev] Convention for TDD In-Reply-To: <20051010170154.GA23762@solar.trillke.net> Message-ID: <20051011055359.90D5C27B56@code1.codespeak.net> Ian, > > >>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? ... > > I'm writing some experimental code, and I want to check it in before it > > is finished. But I want other people to know that it's okay that the > > tests fail (while I also want them to be able to see the code's progress). > > there is no single convention i know off. I guess that > > DONT_TEST_test_whatever > > is the one i have seen most often. Certainly a kludge, but you can set class-level attribute "disabled" to exclude whole test class from running. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: From pinard at iro.umontreal.ca Sat Oct 15 02:46:03 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Fri, 14 Oct 2005 20:46:03 -0400 Subject: [py-dev] py.log suggestion Message-ID: <20051015004603.GA10584@alcyon.progiciels-bpi.ca> 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 From hpk at trillke.net Sat Oct 15 10:21:41 2005 From: hpk at trillke.net (holger krekel) Date: Sat, 15 Oct 2005 10:21:41 +0200 Subject: [py-dev] py.log suggestion In-Reply-To: <20051015004603.GA10584@alcyon.progiciels-bpi.ca> References: <20051015004603.GA10584@alcyon.progiciels-bpi.ca> Message-ID: <20051015082141.GK23762@solar.trillke.net> On Fri, Oct 14, 2005 at 20:46 -0400, Fran?ois Pinard wrote: > > 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) just a quick note (i am no traavel/sprinting) ... yes, thinking about this makes sense. What about making the tracing call callables if they are passed and a consumer is there? cheers, holger From pinard at iro.umontreal.ca Sat Oct 15 14:58:30 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Sat, 15 Oct 2005 08:58:30 -0400 Subject: [py-dev] py.log suggestion In-Reply-To: <20051015082141.GK23762@solar.trillke.net> References: <20051015004603.GA10584@alcyon.progiciels-bpi.ca> <20051015082141.GK23762@solar.trillke.net> Message-ID: <20051015125830.GA24173@alcyon.progiciels-bpi.ca> > > if trace.dossier: > > diagnostic = prepare_diagnostic_information() > > trace.dossier(diagnostic) [holger krekel] > just a quick note (i am no traavel/sprinting) ... Yes, I know you're away :-). > yes, thinking about this makes sense. What about making the tracing > call callables if they are passed and a consumer is there? So one would write: if callable(trace.dossier): diagnostic = prepare_diagnostic_information() trace.dossier(diagnostic) instead? I would still prefer my original suggestion, as it is less verbose. It might probably be implemented by defining ``__nonzero__``. Besides, if ``trace.dossier`` was not always callable, one would ought to resort to a test before using it, instead of calling it blindly (that is, directly without testing first). A blind call is likely the cleanest way to proceed anyway on the average, for when producing the diagnostic text is cheap, which is likely the usual case. -- Fran?ois Pinard http://pinard.progiciels-bpi.ca From hpk at trillke.net Sat Oct 15 15:11:07 2005 From: hpk at trillke.net (holger krekel) Date: Sat, 15 Oct 2005 15:11:07 +0200 Subject: [py-dev] py.log suggestion In-Reply-To: <20051015125830.GA24173@alcyon.progiciels-bpi.ca> References: <20051015004603.GA10584@alcyon.progiciels-bpi.ca> <20051015082141.GK23762@solar.trillke.net> <20051015125830.GA24173@alcyon.progiciels-bpi.ca> Message-ID: <20051015131107.GM23762@solar.trillke.net> On Sat, Oct 15, 2005 at 08:58 -0400, Fran?ois Pinard wrote: > > > if trace.dossier: > > > diagnostic = prepare_diagnostic_information() > > > trace.dossier(diagnostic) > > [holger krekel] > > > just a quick note (i am no traavel/sprinting) ... > > Yes, I know you're away :-). > > > yes, thinking about this makes sense. What about making the tracing > > call callables if they are passed and a consumer is there? > > So one would write: > > if callable(trace.dossier): > diagnostic = prepare_diagnostic_information() > trace.dossier(diagnostic) > > instead? i was thinking of just trace.dossier(prepare_diagnostic_information) actually. If there is no consumer then this would not call the callable. Does that make sense to you? (we could additionally pass any remaining arguments to the callable but that might be hard to conceptually define nicely). cheers, holger From pinard at iro.umontreal.ca Sun Oct 16 16:15:26 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Sun, 16 Oct 2005 10:15:26 -0400 Subject: [py-dev] Thanks a lot for py.test! Message-ID: <20051016141526.GA8007@phenix.progiciels-bpi.ca> 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 From pinard at iro.umontreal.ca Sun Oct 16 18:37:04 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Sun, 16 Oct 2005 12:37:04 -0400 Subject: [py-dev] py.log suggestion In-Reply-To: <20051015131107.GM23762@solar.trillke.net> References: <20051015004603.GA10584@alcyon.progiciels-bpi.ca> <20051015082141.GK23762@solar.trillke.net> <20051015125830.GA24173@alcyon.progiciels-bpi.ca> <20051015131107.GM23762@solar.trillke.net> Message-ID: <20051016163704.GA12038@phenix.progiciels-bpi.ca> > [Fran?ois Pinard] > > > > if trace.dossier: > > > > diagnostic = prepare_diagnostic_information() > > > > trace.dossier(diagnostic) > > if callable(trace.dossier): > > diagnostic = prepare_diagnostic_information() > > trace.dossier(diagnostic) [holger krekel] > i was thinking of just > trace.dossier(prepare_diagnostic_information) > actually. If there is no consumer then this would not call the > callable. Does that make sense to you? Of course, a lot. This is a better idea, that would yield cleaner code. > (we could additionally pass any remaining arguments to the callable > but that might be hard to conceptually define nicely). Could not the producer prototype be a mere: producer(message, *args, **kws) It could implement something like: [...] if any_consumer_besides_None: if callable(message): text = message(*args, **kws) elif args: assert not kws text = message % args elif kws: text = message % kws else: text = message [...] yielding the usual paradigm that message may be a format, for which interpolation does not uselessly occur. Also, the format could use %(keyword)s, with keywords given while calling the producer. About if the `assert' should be there or not rather depends on how forgiving py.log wants to be. I probably yield on the stricter side, also considering that format errors already raise exceptions. -- Fran?ois Pinard http://pinard.progiciels-bpi.ca From grig at gheorghiu.net Sun Oct 16 18:54:14 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Sun, 16 Oct 2005 09:54:14 -0700 (PDT) Subject: [py-dev] Praise heaped on PyPy Message-ID: <20051016165414.76910.qmail@web54505.mail.yahoo.com> 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 From pinard at iro.umontreal.ca Fri Oct 21 22:23:46 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Fri, 21 Oct 2005 16:23:46 -0400 Subject: [py-dev] py.test tracing within generators Message-ID: <20051021202346.GA28529@phenix.sram.qc.ca> 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 From jan at balster.info Sat Oct 22 11:44:24 2005 From: jan at balster.info (Jan Balster) Date: Sat, 22 Oct 2005 11:44:24 +0200 Subject: [py-dev] py.test tracing within generators In-Reply-To: <20051021202346.GA28529@phenix.sram.qc.ca> References: <20051021202346.GA28529@phenix.sram.qc.ca> Message-ID: <435A09F8.50403@balster.info> Fran?ois Pinard wrote: > Hi, people. Hi Fran?ois, can you provide a test case, in which you need this additional information, and what you want to see in the error report? The stack trace includes an indication about which line is active within the generator, if you want to see the variables you can use the --showlocals option of py.test. Or do you want py.test to reinterpret the executed line in the generator, like it is done with the assert statement? cheers, Jan From hpk at trillke.net Sat Oct 22 21:18:09 2005 From: hpk at trillke.net (holger krekel) Date: Sat, 22 Oct 2005 19:18:09 +0000 Subject: [py-dev] py.log suggestion In-Reply-To: <20051016163704.GA12038@phenix.progiciels-bpi.ca> References: <20051015004603.GA10584@alcyon.progiciels-bpi.ca> <20051015082141.GK23762@solar.trillke.net> <20051015125830.GA24173@alcyon.progiciels-bpi.ca> <20051015131107.GM23762@solar.trillke.net> <20051016163704.GA12038@phenix.progiciels-bpi.ca> Message-ID: <20051022191809.GE500@hpk.local> On Sun, Oct 16, 2005 at 12:37 -0400, Fran?ois Pinard wrote: > > [Fran?ois Pinard] > > > > > > if trace.dossier: > > > > > diagnostic = prepare_diagnostic_information() > > > > > trace.dossier(diagnostic) > > > > if callable(trace.dossier): > > > diagnostic = prepare_diagnostic_information() > > > trace.dossier(diagnostic) > > [holger krekel] > > > i was thinking of just > > > trace.dossier(prepare_diagnostic_information) > > > actually. If there is no consumer then this would not call the > > callable. Does that make sense to you? > > Of course, a lot. This is a better idea, that would yield cleaner code. > > > (we could additionally pass any remaining arguments to the callable > > but that might be hard to conceptually define nicely). > > Could not the producer prototype be a mere: > > producer(message, *args, **kws) > > It could implement something like: > > [...] > if any_consumer_besides_None: > if callable(message): > text = message(*args, **kws) > elif args: > assert not kws > text = message % args > elif kws: > text = message % kws > else: > text = message > [...] > > yielding the usual paradigm that message may be a format, for which > interpolation does not uselessly occur. Also, the format could use > %(keyword)s, with keywords given while calling the producer. I see the use of being able to lazify interpolation but it puts the producer even further away from the print statement. Also it's incompatible to current usage. Currently print x, "hello", z is mostly equivalent to mylog(x, "hello", z) and somehow i'd like to keep it that way. But if we just special case the first argument being callable (which is already somewhat on the risky side because you may want to put arbitrary objects there which might have a __call__ although you just want to see them __repr__'ed) then you could use e.g. mylog("hello %(x)s".__mod__ , x=3) in which case people would learn what the percent-operator actually translates to at the same time :-) So, in short, i propose to treat the case of the first arg being a callable, simply as: if consumer is not None: if args and callable(args[0]): args = args[0](*args[1:], **kwargs) kwargs = None ... (you could make the 'if' even a 'while' :-) what do you think? holger From hpk at trillke.net Sat Oct 22 21:01:24 2005 From: hpk at trillke.net (holger krekel) Date: Sat, 22 Oct 2005 19:01:24 +0000 Subject: [py-dev] Thanks a lot for py.test! In-Reply-To: <20051016141526.GA8007@phenix.progiciels-bpi.ca> References: <20051016141526.GA8007@phenix.progiciels-bpi.ca> Message-ID: <20051022190124.GD500@hpk.local> Hi Fran??ois! On Sun, Oct 16, 2005 at 10:15 -0400, Fran?ois Pinard wrote: > Hi, people. I just wanted to share my enthusiasm for py.test. much appreciated :-) > 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. Sounds good. > 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! :-) hehe. Actually we should also think about how to allow disabling tests at module level or even at directoy level, i guess. OTOH, there is the long standing idea of properly connecting tags/keywords to tests on directory, module and class level (these would all apply to groups of test) and directly on a test function. Implementing this as static tags should be rather straight forward. On a more far fetched note, dynamic tags could be assigned to test functions unintrusively, e.g. assigning "speed" tags like "slow/bearable/fast". Such "dynamic tags" could be assigned during a regular test run along with "failed" or "skipped" information. This way one could run all previously failing tests without having to use "--looponfailing". The main missing piece to implement this nicely is a concept to store such state. > 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. Yes, although that area could need some clarifications and refinements. When it comes to "conftest.py" files there is a lot that you can do, basically take over test collecting and running in subdirectories which is what is done for ReST or for PyPy. > 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! hehe, many thanks for your feedback! might make it to the web page some time, if you don't mind :-) cheers, holger From hpk at trillke.net Sun Oct 23 10:22:44 2005 From: hpk at trillke.net (holger krekel) Date: Sun, 23 Oct 2005 08:22:44 +0000 Subject: [py-dev] Thanks a lot for py.test! In-Reply-To: <20051022190124.GD500@hpk.local> References: <20051016141526.GA8007@phenix.progiciels-bpi.ca> <20051022190124.GD500@hpk.local> Message-ID: <20051023082244.GS500@hpk.local> On Sat, Oct 22, 2005 at 19:01 +0000, holger krekel wrote: > Hi Fran??ois! Well, i guess i have some problems with my email setup (which i am changing anyway to be able to work more offline from my laptop). Until i get to it i probably resort to not using non-ascii characters :-) holger From pinard at iro.umontreal.ca Wed Oct 26 04:22:23 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Tue, 25 Oct 2005 22:22:23 -0400 Subject: [py-dev] py.log suggestion In-Reply-To: <20051022191809.GE500@hpk.local> References: <20051015004603.GA10584@alcyon.progiciels-bpi.ca> <20051015082141.GK23762@solar.trillke.net> <20051015125830.GA24173@alcyon.progiciels-bpi.ca> <20051015131107.GM23762@solar.trillke.net> <20051016163704.GA12038@phenix.progiciels-bpi.ca> <20051022191809.GE500@hpk.local> Message-ID: <20051026022223.GA9498@alcyon.progiciels-bpi.ca> [holger krekel] > I see the use of being able to lazify interpolation but it puts the > producer even further away from the print statement. Also it's > incompatible to current usage. Currently > print x, "hello", z > is mostly equivalent to > mylog(x, "hello", z) > and somehow i'd like to keep it that way. Oh! I did not know that similarity with ``print``, which I always perceived as a debugging statement -- I can blindly get rid of any ``print`` statements at any time in my programs). No doubt I can tame myself to the above! :-) > mylog("hello %(x)s".__mod__ , x=3) Hmph! That's too clever to be really useful! :-). > So, in short, i propose to treat the case of the first arg > being a callable, simply as: > if consumer is not None: > if args and callable(args[0]): > args = args[0](*args[1:], **kwargs) > kwargs = None > ... It surely solves the initial problem, anyway, which is to have some way to conditionalise out semi-lengthy computations whose sole purpose is to generate the text of log messages. > (you could make the 'if' even a 'while' :-) > what do you think? Maybe, yet there is a slight danger that logging be less fun, if it was requiring too much attention, and was a bit prone at creating looping problems or other obscure bugs, that would distract users away from the outside problems they are scrutinizing. Or maybe I'm over-cautious, it's not easy to predict where is the correct equilibrium. And there is this unexpected danger as well, which you underlined in one of your replies, and which I did not foresee (I should probably have), that mylog may receive a first argument which is unexpectedly callable. I hope it would not be much of a practical problem, and would feel ready to take the risk and use it, just to acquire some experience about if it creates practical problems, or not. P.S. - Sorry for the delay in replying. Job pressure is high in these days! -- Fran?ois Pinard http://pinard.progiciels-bpi.ca From hpk at trillke.net Fri Oct 28 10:30:41 2005 From: hpk at trillke.net (holger krekel) Date: Fri, 28 Oct 2005 08:30:41 +0000 Subject: [py-dev] py.log suggestion In-Reply-To: <20051026022223.GA9498@alcyon.progiciels-bpi.ca> References: <20051015004603.GA10584@alcyon.progiciels-bpi.ca> <20051015082141.GK23762@solar.trillke.net> <20051015125830.GA24173@alcyon.progiciels-bpi.ca> <20051015131107.GM23762@solar.trillke.net> <20051016163704.GA12038@phenix.progiciels-bpi.ca> <20051022191809.GE500@hpk.local> <20051026022223.GA9498@alcyon.progiciels-bpi.ca> Message-ID: <20051028083041.GI25572@hpk.local> Hey Francois, On Tue, Oct 25, 2005 at 22:22 -0400, Fran?ois Pinard wrote: > [holger krekel] > > > I see the use of being able to lazify interpolation but it puts the > > producer even further away from the print statement. Also it's > > incompatible to current usage. Currently > > > print x, "hello", z > > > is mostly equivalent to > > > mylog(x, "hello", z) > > > and somehow i'd like to keep it that way. > > Oh! I did not know that similarity with ``print``, which I always > perceived as a debugging statement -- I can blindly get rid of any > ``print`` statements at any time in my programs). > > No doubt I can tame myself to the above! :-) :-) > > mylog("hello %(x)s".__mod__ , x=3) > > Hmph! That's too clever to be really useful! :-). ok, ok :) > > So, in short, i propose to treat the case of the first arg > > being a callable, simply as: > > > if consumer is not None: > > if args and callable(args[0]): > > args = args[0](*args[1:], **kwargs) > > kwargs = None > > ... > > It surely solves the initial problem, anyway, which is to have some way > to conditionalise out semi-lengthy computations whose sole purpose is to > generate the text of log messages. > > > (you could make the 'if' even a 'while' :-) > > what do you think? > > Maybe, yet there is a slight danger that logging be less fun, if it was > requiring too much attention, and was a bit prone at creating looping > problems or other obscure bugs, that would distract users away from the > outside problems they are scrutinizing. Or maybe I'm over-cautious, > it's not easy to predict where is the correct equilibrium. Well, the "while" really was a joke. > And there is this unexpected danger as well, which you underlined in one > of your replies, and which I did not foresee (I should probably have), > that mylog may receive a first argument which is unexpectedly callable. Right. So i have a new suggestion. log.info[arg1, arg2, ...] would behave exactly like the log.info(arg1, arg2, ...) does now, i.e. a dumb "print" emulation. No special check for callables, formatting and such. But then we can put the "call function" syntax to new usage. So with log.info(*args, **kwargs) we would now have special treatment (rough sketch): ... if consumer is not None: if callable(args[0]): consumer(args[0](*args[1:], **kwargs)) else: if kwargs: assert len(args) == 1, "..." consumer(args[0] % kwargs) else: assert not kwargs, "..." consumer(args[0] % args[1:]) this should IMO allow a rather intuitive usage for percent-formatting as well as for defering formatting to custom callables. This is unfortunately a somewhat incompatible change to current usage but well, it's not used that much yet and we probably have enough access to the code bases that currently use it. > P.S. - Sorry for the delay in replying. Job pressure is > high in these days! he, no problem! what do you think goes on here? :) cheers, holger From pinard at iro.umontreal.ca Fri Oct 28 16:52:24 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Fri, 28 Oct 2005 10:52:24 -0400 Subject: [py-dev] Thanks a lot for py.test! In-Reply-To: <20051022190124.GD500@hpk.local> References: <20051016141526.GA8007@phenix.progiciels-bpi.ca> <20051022190124.GD500@hpk.local> Message-ID: <20051028145224.GA26893@phenix.sram.qc.ca> [holger krekel] > Actually we should also think about how to allow disabling tests at > module level or even at directory level, i guess. At module level, it could be a mere "disabled" global variable. That would nicely parallel what happens at class level. For individual function level (if ever needed), it could be a "disabled" attribute to the function itself. Maybe! > [...] there is the long standing idea of properly connecting > tags/keywords to tests on directory, module and class level (these > would all apply to groups of test) and directly on a test function. > Implementing this as static tags should be rather straight forward. I did not witness previous discussions on this topic, so the following naive ideas. Could it be a "tags" variable, usable in exactly same contexts as "disabled"? Its value could be a tuple of strings, or a single string. Written without parentheses, of course! :-) This being tied to some ``-t TAGS`` option to the py.test driver. > When it comes to "conftest.py" files there is a lot that you can do, > basically take over test collecting and running in subdirectories > which is what is done for ReST or for PyPy. The documentation lets me with the feeling one could do a lot. But so far, I do not think I needed that lot. :-) I have a lot already. > > 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! > hehe, many thanks for your feedback! might make it to the > web page some time, if you don't mind :-) No problem with me. If you ever do, please be kind enough to correct my English mistakes (orthographical or stylistic). -- Fran?ois Pinard http://pinard.progiciels-bpi.ca From pinard at iro.umontreal.ca Fri Oct 28 17:00:45 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Fri, 28 Oct 2005 11:00:45 -0400 Subject: [py-dev] Thanks a lot for py.test! In-Reply-To: <20051023082244.GS500@hpk.local> References: <20051016141526.GA8007@phenix.progiciels-bpi.ca> <20051022190124.GD500@hpk.local> <20051023082244.GS500@hpk.local> Message-ID: <20051028150045.GB26893@phenix.sram.qc.ca> [holger krekel] > Well, i guess i have some problems with my email setup [...] Until i > get to it i probably resort to not using non-ascii characters :-) For my French correspondents, I'm a bit anal and ask people to write French with the proper diacritics. For Americans and other diacritic-deficient nations :-), I'm much more forgiving, and "Francois" is just OK! To respect the intent of the diacritic in my name without writing it, one may resort to transliteration, like in "Franc,ois". A tiny unusual detail I noticed, in email originating from you, is that each line has one, sometimes two, spurious spaces at its end. (So you now see the kind of nit-picker I may be. Yet, otherwise, a good guy!) -- Fran?ois Pinard http://pinard.progiciels-bpi.ca From pinard at iro.umontreal.ca Sat Oct 29 05:09:30 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Fri, 28 Oct 2005 23:09:30 -0400 Subject: [py-dev] Holger and RFC 2646 Message-ID: <20051029030930.GA19289@phenix.sram.qc.ca> 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 From hpk at trillke.net Sun Oct 30 17:57:05 2005 From: hpk at trillke.net (holger krekel) Date: Sun, 30 Oct 2005 16:57:05 +0000 Subject: [py-dev] Holger and RFC 2646 In-Reply-To: <20051029030930.GA19289@phenix.sram.qc.ca> References: <20051029030930.GA19289@phenix.sram.qc.ca> Message-ID: <20051030165705.GJ363@hpk.local> Hi Francois, On Fri, Oct 28, 2005 at 23:09 -0400, Fran?ois Pinard wrote: > 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! he, that's good to know :) Some people e.g. in the pypy-group have been complaining about this already. finally-having-a-justification'ly yours, holger From pinard at iro.umontreal.ca Sun Oct 30 22:50:27 2005 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Sun, 30 Oct 2005 16:50:27 -0500 Subject: [py-dev] Holger and RFC 2646 In-Reply-To: <20051030165705.GJ363@hpk.local> References: <20051029030930.GA19289@phenix.sram.qc.ca> <20051030165705.GJ363@hpk.local> Message-ID: <20051030215027.GA16649@alcyon.progiciels-bpi.ca> [holger krekel] > [Fran?ois Pinard] >> 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. >he, that's good to know :) Some people e.g. in the pypy-group have >been complaining about this already. After your emails, I decided to experiment "f=f" for my own outgoing email, and see what happens. I use Mutt and Vim here. Mutt does nothing special to flow incoming email, so this is not useful to me, but maybe it could be useful for some of my correspondents nevertheless. It was really a simple matter to setup. Within ~/.mutt/muttrc, I added this line: set text_flowed and within ~/.vim/ftplugin/mail.vim, these lines: set formatoptions+=aw set textwidth=72 map Q gqap The last one was needed, in my case, to override this ~/.vimrc line: map Q !appar} as par does not understand "f=f" conventions, while Vim does. -- Fran?ois Pinard http://pinard.progiciels-bpi.ca