[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Sun Mar 9 12:00:00 2008 UTC to Mon Mar 10 12:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Sun Mar 9 21:59:59 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-March/009225.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sun Mar 9 22:01:29 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-March/009226.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sun Mar 9 22:02:59 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-March/009227.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sun Mar 9 22:04:30 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-March/009228.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sun Mar 9 22:06:01 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-March/009229.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Directory resource factories
Thanks for creating this. I just (finally) commented. Jim On Feb 29, 2008, at 6:50 PM, Malthe Borch wrote: Jim Fulton wrote: +1. Some more details would need to be worked out. For example, to work for your use case, it would need to be involved in search, or the searching rules would need to be made more powerful, so, when looking for some file name, it is prepared to consider files that have the file name as a base and use some additional extension, as in your example. I would love to see someone work this out. A proposal would be appreciated. I added a proposal here: http://wiki.zope.org/zope3/FileSystemResources \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: I did a five-minute skim of the checkin but hope to look a bit more tomorrow. Hopefully Marius, Benji, Albertas, or someone else who has actually done work on this package will take a look and chime in. I did have one somewhat trivial thought. I generally prefer durations and intervals expressed as datetime.timedeltas myself, because they convey their meaning without having to look it up docs (is that number value a number of seconds? milliseconds? minutes?). There might even be a zcml built in for schema field for that; I believe I remember that there is in ZConfig. Also, some variety of doctest would be nice. Even when a package is not using doctests, I add new tests as doctest unless there's a really good reason not to. Becuase they make for poor unit tests? Using them to document the mainline use cases for an API is one thing: using them to do thorough coverage of edge cases is quite another. I find that for the latter, they fail *both* as documentation *and* as tests: their value as documentation drops as the amount of scaffoldiing rises, and the lack of isolation between tests sharply reduces their value for testing the corners. I realize I have said this before, but then others keep urging the doctests everywhere meme. In this case, it looks like you've made the code significantly more robust, which has added some probably necessary complexity. The code looks readable, but I recommend a maintainer-oriented overview/ introduction as a doctest, at the least. For instance, perhaps you could think about documentation about the rationale for the approach and about the dance that this code participates in (with the lock files and all the possible SMTP error conditions and the code's responses). Of course, even more friendly docs than that would be nice, but I'm only asking for what I myself tend to give, unfortunately. I would also value such documntation, but doubt that the scaffolding necessary to make the doctest part of the dance executable would make it any more valuable. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1WRV+gerLs4ltQ4RAqHKAJ4lQgwkiCFIk1YpE6oon+xBbDT0sgCfa2M9 Uer6lWCkZh701UyspIzVso4= =5qeo -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Directory resource factories
Jim Fulton wrote: Thanks for creating this. I just (finally) commented. I've elaborated on that paragraph. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
Previously Tres Seaver wrote: Gary Poster wrote: I did a five-minute skim of the checkin but hope to look a bit more tomorrow. Hopefully Marius, Benji, Albertas, or someone else who has actually done work on this package will take a look and chime in. I did have one somewhat trivial thought. I generally prefer durations and intervals expressed as datetime.timedeltas myself, because they convey their meaning without having to look it up docs (is that number value a number of seconds? milliseconds? minutes?). There might even be a zcml built in for schema field for that; I believe I remember that there is in ZConfig. Also, some variety of doctest would be nice. Even when a package is not using doctests, I add new tests as doctest unless there's a really good reason not to. Becuase they make for poor unit tests? Using them to document the mainline use cases for an API is one thing: using them to do thorough coverage of edge cases is quite another. I find that for the latter, they fail *both* as documentation *and* as tests: their value as documentation drops as the amount of scaffoldiing rises, and the lack of isolation between tests sharply reduces their value for testing the corners. I realize I have said this before, but then others keep urging the doctests everywhere meme. Indeed, and for that reason this can't be said enough. Doctests are useful to create testable documentation. They are not the right tool to create isolated, debuggable tests. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
Wichert Akkerman wrote: Previously Tres Seaver wrote: I realize I have said this before, but then others keep urging the doctests everywhere meme. Indeed, and for that reason this can't be said enough. Doctests are useful to create testable documentation. They are not the right tool to create isolated, debuggable tests. Not everyone agrees with this assertion. I for one vastly prefer both to read and write unity doctests over classic unit tests. And as doctests everywhere is the current status quo for just about the entire code base, I would expect a very convincing argument to be required to change. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
On Mar 10, 2008, at 17:57 , Wichert Akkerman wrote: Previously Tres Seaver wrote: Gary Poster wrote: Also, some variety of doctest would be nice. Even when a package is not using doctests, I add new tests as doctest unless there's a really good reason not to. Becuase they make for poor unit tests? Using them to document the mainline use cases for an API is one thing: using them to do thorough coverage of edge cases is quite another. I find that for the latter, they fail *both* as documentation *and* as tests: their value as documentation drops as the amount of scaffoldiing rises, and the lack of isolation between tests sharply reduces their value for testing the corners. I realize I have said this before, but then others keep urging the doctests everywhere meme. Indeed, and for that reason this can't be said enough. Doctests are useful to create testable documentation. They are not the right tool to create isolated, debuggable tests. Amen to that. Doctests are a useful testing tool, but no single tool can fit every situation. jens ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
Previously Benji York wrote: Wichert Akkerman wrote: Previously Tres Seaver wrote: I realize I have said this before, but then others keep urging the doctests everywhere meme. Indeed, and for that reason this can't be said enough. Doctests are useful to create testable documentation. They are not the right tool to create isolated, debuggable tests. Not everyone agrees with this assertion. I for one vastly prefer both to read and write unity doctests over classic unit tests. And as doctests everywhere is the current status quo for just about the entire code base, I would expect a very convincing argument to be required to change. The fact that something is popular does not necessarily mean it is the right thing :) Lack of isolation is a very convincing argument to me. Perhaps more personal taste but I also find python unittests to be much more readable. You don't suffer from mixing lots of test setup/teardown being repeated through the file. As Tres mentioned this is especially true when testing corner cases. Being able to debug tests by stepping over them with pdb is incredibly useful. With doctests that doesn't work. Being able to run a single test easily allows for quick testing and debugging. I can't tell the testrunner 'start running at line 52 but also include all the test setup magic from before, but skip the rest'. With unittests I can simple run zopectl test -s module -t test function. doctests hurt my productivity badly. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
On Mon, Mar 10, 2008 at 6:09 PM, Wichert Akkerman [EMAIL PROTECTED] wrote: The fact that something is popular does not necessarily mean it is the right thing :) Lack of isolation is a very convincing argument to me. Perhaps more personal taste but I also find python unittests to be much more readable. You don't suffer from mixing lots of test setup/teardown being repeated through the file. As Tres mentioned this is especially true when testing corner cases. Being able to debug tests by stepping over them with pdb is incredibly useful. With doctests that doesn't work. Being able to run a single test easily allows for quick testing and debugging. I can't tell the testrunner 'start running at line 52 but also include all the test setup magic from before, but skip the rest'. With unittests I can simple run zopectl test -s module -t test function. doctests hurt my productivity badly. I completely agree with Tres' and Wichert's statements on this. I only use doctests where they actually would make sense as documentation, the corner cases I always write as unit tests. The tools for dealing with pure Python code are so much more powerful than for python-embedded-in-text-with-prefixes, as well. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
Wichert Akkerman wrote: The fact that something is popular does not necessarily mean it is the right thing :) Very true. It does, however, mean that you have to have a convincing argument to change popular opinion. Lack of isolation is a very convincing argument to me. This almost never bites me (if I'm understanding you correctly). Perhaps more personal taste but I also find python unittests to be much more readable. You don't suffer from mixing lots of test setup/teardown being repeated through the file. As Tres mentioned this is especially true when testing corner cases. Footnotes and good test structure alleviate the need for in-line setup/teardown. Being able to debug tests by stepping over them with pdb is incredibly useful. With doctests that doesn't work. As a heavy pdb user, this rarely bothers me, but seems to be more of an implementation issue than an argument that doctests are bad for unit tests. Being able to run a single test easily allows for quick testing and debugging. I can't tell the testrunner 'start running at line 52 but also include all the test setup magic from before, but skip the rest'. With unittests I can simple run zopectl test -s module -t test function. I don't see a huge advantage over bin/test -s package -t doctest file name doctests hurt my productivity badly. shrug I guess I'm the odd-man-out. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
On Mar 10, 2008, at 12:39 PM, Tres Seaver wrote: Gary Poster wrote: [...] Doctest/unittest holy war: bah. I've heard the arguments, I don't see either side as perfect, and I've made my choice. I'm very fine with others having different opinions and choices. As Benji said, the doctest choice has been made for the zope.* tree, so, until the current choice changes, it's reasonable to encourage doctests for zope.sendmail. If folks want to agitate for more unit tests in zope.*, have at it, but that doesn't change where we are now. BTW, Wichert, trying to be helpful: if you do have to deal with someone else's doctests, you can in fact use pdb. Just put the set_trace() on the same line as the command you want to step into. You can't step into subsequent doctest lines, but that does not tend to cause me too many problems, IME. Maybe that's your complaint, though. (To be clear, Wichert, I grant the validity of other points you and Tres and others made. There are counter-arguments, and matters of taste. Other folks can argue about this, not me.) In this case, it looks like you've made the code significantly more robust, which has added some probably necessary complexity. The code looks readable, but I recommend a maintainer-oriented overview/ introduction as a doctest, at the least. For instance, perhaps you could think about documentation about the rationale for the approach and about the dance that this code participates in (with the lock files and all the possible SMTP error conditions and the code's responses). Of course, even more friendly docs than that would be nice, but I'm only asking for what I myself tend to give, unfortunately. I would also value such documntation, but doubt that the scaffolding necessary to make the doctest part of the dance executable would make it any more valuable. Here's one disagreement I'll bother to stand up for. Making documentation testable does add value to technical docs like this, in that it encourages it to stay up-to-date with refactorings. It is certainly not perfect--the examples can be tested but not the exposition--but saying that it does not add value in this case seems extreme to me. Perhaps your argument, Tres, is that the effort outweighs the cost in this particular case. That's a more reasonable argument to me. Maybe the scaffolding will be arduous. However, I would expect that some approaches to the doctest scaffolding would in fact mirror the set up needed for the unit tests, and I'd encourage Matthew to give it a try before immediately giving up. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
Gary Poster wrote: Perhaps your argument, Tres, is that the effort outweighs the cost in this particular case. That's a more reasonable argument to me. Maybe the scaffolding will be arduous. I can certainly get on board with that argument.. I, myself, have added small unit tests to zope.sendmail. At the time I contemplated converting the tests to doctest, but it looked too painful because I didn't understand the meaning behind the assertions being made in the current tests. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sendmail Retry fixes and new state machine.
On Sun, Mar 9, 2008 at 7:54 PM, Gary Poster [EMAIL PROTECTED] wrote: I did have one somewhat trivial thought. I generally prefer durations and intervals expressed as datetime.timedeltas myself, because they convey their meaning without having to look it up docs (is that number value a number of seconds? milliseconds? minutes?). There might even be a zcml built in for schema field for that; I believe I remember that there is in ZConfig. ZConfig supports two datatypes for time deltas: time-interval is a number of seconds, provided as a float. In a configuration file, a slightly more readable expression is used. For example, 4d 3h 2m 1s means 4 days 3 hours 2 minutes 1 second. timedelta is a datetime.timedelta value. The syntax in the configuration file is the same as for time-interval. Neither allows specifying a negative delta value; they're really about an interval rather than a delta. Fortunately, that covers most configuration uses. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
Benji York wrote at 2008-3-10 13:03 -0400: Wichert Akkerman wrote: Indeed, and for that reason this can't be said enough. Doctests are useful to create testable documentation. They are not the right tool to create isolated, debuggable tests. Not everyone agrees with this assertion. I for one vastly prefer both to read and write unity doctests over classic unit tests. And as doctests everywhere is the current status quo for just about the entire code base, I would expect a very convincing argument to be required to change. Looks at the ZODB tests. They make heavy use of multiple inheritance to compose test classes out of component test classes and use the same tests e.g. for FileStorage as well as for ZEO tests. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
On Monday 10 March 2008, Wichert Akkerman wrote: Indeed, and for that reason this can't be said enough. Doctests are useful to create testable documentation. They are not the right tool to create isolated, debuggable tests. Huh? I totally disagree. If you cannot explain your software in words, you do not understand it. As there are different kinds of programmatic tests, you can easily write different levels of doctests that have different audiences. I do this all the time. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
On Monday 10 March 2008, Martijn Pieters wrote: I completely agree with Tres' and Wichert's statements on this. I only use doctests where they actually would make sense as documentation, the corner cases I always write as unit tests. The tools for dealing with pure Python code are so much more powerful than for python-embedded-in-text-with-prefixes, as well. In my opinion it is as necessary to describe corner cases with words. In fact, corner cases often need even more documentation, because they are not obvious. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
--On 10. März 2008 22:33:13 -0500 Stephan Richter [EMAIL PROTECTED] wrote: On Monday 10 March 2008, Wichert Akkerman wrote: Indeed, and for that reason this can't be said enough. Doctests are useful to create testable documentation. They are not the right tool to create isolated, debuggable tests. Huh? I totally disagree. If you cannot explain your software in words, you do not understand it. As there are different kinds of programmatic tests, you can easily write different levels of doctests that have different audiences. This sounds like writing doctests just for sake of having doctests for all and everything. I completely disagree with that. In complex algorithms edgecases are often only of interest for the person implementing the code in order for having a safety belt. For writing good doctests you have to be a good (English) writer at some point. Doctests come into the game if you want to tell other people about the usage of your module. It's basically not of interest for telling them all edgecases. Addressing edgecase is unittests is basically good enough for me. They sometime require more code to test and put this into a doctest is often just overhead. Andreas pgpNQuUhN2HLl.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
