Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
On 2009-12-2 23:06, Marius Gedminas wrote: > On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote: >> Here's another idea: a testrunner option that takes a file name and line >> number and inserts a breakpoint at that position. That way you can get >> the same effect as editing the code without actually having to do so. > > Is that possible? I once spent hours studying pdb docs and found no way > to set a breakpoint in advance, without modifying the source file in > question, and without having the user to do manual interaction at the > beginning. I think mr.freeze (see http://pypi.python.org/pypi/mr.freeze ) can do this. Perhaps there is some code there you could borrow. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCA summary so far...
My $.02 is here: http://www.plope.com/Members/chrism/zca_thoughts_summary Gary Poster wrote: > ...from my perspective. > > = Things vaguely approaching consensus = > > == General == > > There's a consensus that changes to the ZCA need to be backwards compatible. > The practical definition of that varies for different people. > > == Syntactic == > > === Tuple multi-adaptation === > > Example: > IFoo((bar, baz)) == z.c.getMultiAdapter((bar, baz), IFoo) > > - It has the most consensus of any proposed change so far. > > - It is concerning because it breaks backwards compatibility in two real > world use cases from the very small set of Zope users who actually watch > zope-dev. There is a workaround spelling at least, but it is ugly (i.e., > what was ``IFoo((bar, baz))`` will need to become ``IFoo(((bar, baz),))``). > > - It is easier to remember than ``z.c.getMultiAdapter((bar, baz), IFoo)`` (I > always have to look up the order of arguments for getMultiAdapter myself) but > not as easy to remember as ``IFoo(bar, baz)``. It introduces yet another > spelling of the same thing (e.g., ``IFoo(bar)`` is the same as > ``IFoo((bar,))``. > > == Utilities available from interfaces == > > As far as I can tell, no one is against this generally, and several people > are for it. Some people are against the syntax that has been proposed for > this that merges utilties and adapters (see "No consensus" section below). > An alternate syntax was proposed involving a ``utility`` callable. This made > the most sense when it was paired with an ``adapters`` (or ``factory`` or > ``new`` or ``instance`` or ``create``) callable, which contradicts the > consensus of the "tuple multi-adaptation" section above. > > > > = No consensus AFAICT = > > - Utilities and adapters should be merged. > > - We care significantly about new and casual users and perceive that the > current API does not serve them well. > > - Adapters are usually used as factories, and utilities are used as > instances, and it is valuable to present them that way. Related: the term > "adapter" buys us little and costs us more than nothing among new and casual > users. > > > > = Rejected = > > - Utilities should be called singletons. > > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On 11/30/2009 10:05 AM, Brian Sutherland wrote: > On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote: >> On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver wrote: >>> Hmm, I may be missing something here, but if Foo implements IFoo, then >>> the getAdapter lookup for it will short circuit, leading you into >>> infinite recursion. Except that it doesn't: >> >> [snip example] >> >>> which strikes me as wildly disjoint: the IFoo behavior is "expected" >>> (short-circuit the lookup if the object already provides the interface), >>> while the getAdapter behavior is a puzzlement. >> >> This has been mentioned numerous times as one of those odd and >> unexpected differences between the IFoo vs. get/queryAdapter semantic. >> IIRC the only use-case I ever heard of for the getAdapter semantic, >> was the possibility to override the behavior promised by the interface >> with a different adapter without touching the class that implements >> the interface directly. >> >> I think changing this falls into the category of: Small backwards >> incompatibly that seem worthwhile to make the behavior consistent and >> expected. > > I do agree that this behaviour is inconsistent with the common idea of > adapters in the ZCA. So it doesn't have to be in the "main API" to the > ZCA, i.e. the one people most heavily and frequently use. > > But, I'll argue that it should be still possible if you are willing to > go outside the main API. > > My particular usecase is Location objects implementing IPublishTraverse > without depending on the default traversal adapter: > > class FakeContainerOfSomeKind(Location): > > implements(IPublishTraverse) > > def publishTraverse(self, request, name): > if name.isdigit() and do_i_contain(name): > return get_the_object_i_contain(name) > # fallback to default traversal adapter without depending on it > traverser = getMultiAdapter((self, request), IPublishTraverse) > return traverser.publishTraverse(request, name) > > I wouldn't know how to implement the above code without either depending > directly on the default traversal adapter or making an > IDefaultPublishTraverse marker interface. Neither of those, in my > opinion, is as elegant as the above. That reminds me that I had the occasional wish to invoke the ZCA using some kind of chaining mechanism so that an adapter can ask for the next less specific adapter that would have been invoked if the former wasn't there. The use case is similar: delegate to a default. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCA proposal
Gary Poster wrote: > I think I could get fully behind the following proposal that others have made > (Shane I think was one of several?). > > IFoo.adapt(...) > > IFoo.utility(...) Thinking about it a bit, it strikes me that IFoo.adapt(context) may not be right. This reads "IFoo adapt context", which doesn't make sense. What I really want to hear is "context adapted to IFoo". So maybe it's IFoo.adapting(context)? IFoo.adapterFor(context)? IFoo.adapter(context)? Just thinking out loud. Thinking out loud further, I think I may actually prefer IFoo.instance() instead of .utility(), but maybe that debate is already passed. .utility() is OK too. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCA proposal
Gary Poster wrote: > On Dec 2, 2009, at 11:09 PM, Martin Aspeli wrote: > >> Gary Poster wrote: >>> I think I could get fully behind the following proposal that >>> others have made (Shane I think was one of several?). >>> >>> IFoo.adapt(...) >>> >>> IFoo.utility(...) >> I could get behind this too. >> >> We'd need the current IFoo(context, default) for single adaptation >> to continue to work, and I *wouldn't* deprecate it with a warning, >> since it'd just lead to a lot of warnings. We'd obviously also want >> the existing get*() methods to continue to work. > > Not sure which get* you mean (get* and query* in ZCA?) but generally > agree that we are talking about adding, not removing. Sorry, yeah - getMultiAdapter(), getAdapter(), getUtility() and their query equivalents. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCA proposal
On Dec 2, 2009, at 11:09 PM, Martin Aspeli wrote: > Gary Poster wrote: >> I think I could get fully behind the following proposal that others >> have made (Shane I think was one of several?). >> >> IFoo.adapt(...) >> >> IFoo.utility(...) > > I could get behind this too. > > We'd need the current IFoo(context, default) for single adaptation to > continue to work, and I *wouldn't* deprecate it with a warning, since > it'd just lead to a lot of warnings. We'd obviously also want the > existing get*() methods to continue to work. Not sure which get* you mean (get* and query* in ZCA?) but generally agree that we are talking about adding, not removing. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCA proposal
Gary Poster wrote: > I think I could get fully behind the following proposal that others > have made (Shane I think was one of several?). > > IFoo.adapt(...) > > IFoo.utility(...) I could get behind this too. We'd need the current IFoo(context, default) for single adaptation to continue to work, and I *wouldn't* deprecate it with a warning, since it'd just lead to a lot of warnings. We'd obviously also want the existing get*() methods to continue to work. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZCA proposal
I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) = Why? = - This is a significant improvement in terms of being memorable, as far as I'm concerned. It's also briefer, which is related. - It uses the terms we've already taught. - It is entirely backwards compatible. We don't have to poll the world and hope we didn't miss anyone. - We can make the call syntax for ``adapt`` take multiple arguments. - It is symmetric-ish. - It would potentially allow a place to hang debug/analysis calls, as I showed earlier, but let's not have that debate yet. I can put those somewhere else if I need to. = Why not tuple multi-adaptation in the __call__? = I'm somewhat surprised that some who have been loudest about not breaking backwards compatibility are OK with breaking this, given the two reports from the very small sample we have here of users. I think it is unnecessarily risky for minimal gain, particularly when we have another reasonable option. = But Gary, I thought you didn't like ``adapt``? = No, I don't. I think it is a hindrance to understanding, and I would prefer ``instance``, for example (or maybe ``create``?). That said, people disagree with me. Going along with ``adapt`` but getting this new syntax gets me a lot of improvements from my perspective. I think people on the Launchpad team would be happy with this. I would explain ``adapt`` as "look, it's a factory," but, oh well. Progress usually means compromise. = But Gary, I thought you didn't like ``utility``? = No, I don't. I already gave up on that one, since I didn't have an answer better than "singleton" and I acknowledge that it is not great (either, for different reasons). Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZCA summary so far...
...from my perspective. = Things vaguely approaching consensus = == General == There's a consensus that changes to the ZCA need to be backwards compatible. The practical definition of that varies for different people. == Syntactic == === Tuple multi-adaptation === Example: IFoo((bar, baz)) == z.c.getMultiAdapter((bar, baz), IFoo) - It has the most consensus of any proposed change so far. - It is concerning because it breaks backwards compatibility in two real world use cases from the very small set of Zope users who actually watch zope-dev. There is a workaround spelling at least, but it is ugly (i.e., what was ``IFoo((bar, baz))`` will need to become ``IFoo(((bar, baz),))``). - It is easier to remember than ``z.c.getMultiAdapter((bar, baz), IFoo)`` (I always have to look up the order of arguments for getMultiAdapter myself) but not as easy to remember as ``IFoo(bar, baz)``. It introduces yet another spelling of the same thing (e.g., ``IFoo(bar)`` is the same as ``IFoo((bar,))``. == Utilities available from interfaces == As far as I can tell, no one is against this generally, and several people are for it. Some people are against the syntax that has been proposed for this that merges utilties and adapters (see "No consensus" section below). An alternate syntax was proposed involving a ``utility`` callable. This made the most sense when it was paired with an ``adapters`` (or ``factory`` or ``new`` or ``instance`` or ``create``) callable, which contradicts the consensus of the "tuple multi-adaptation" section above. = No consensus AFAICT = - Utilities and adapters should be merged. - We care significantly about new and casual users and perceive that the current API does not serve them well. - Adapters are usually used as factories, and utilities are used as instances, and it is valuable to present them that way. Related: the term "adapter" buys us little and costs us more than nothing among new and casual users. = Rejected = - Utilities should be called singletons. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Releasing zope.browserresource
On Thu, Nov 26, 2009 at 4:57 AM, Wichert Akkerman wrote: > On 2009-11-26 08:43, Michael Howitz wrote: >> Am 25.11.2009 um 15:49 schrieb Chris Withers: >> [...] >>> Yes, PyPI is broken if you're an admin of many packages, feel free to >>> "me too" on this issue: >>> >>> http://sourceforge.net/tracker/?func=detail&aid=2793544&group_id=66150&atid=513503 >> >> It's fixed since yesterday. > > That's not a fix, it just replaced one problem with another one: it is > now impossible to get your full list of packages. I've submitted a patch that removes the truncation behavior and makes the list scroll instead. Feel free to +1 the issue if you feel so moved: https://sourceforge.net/tracker/?func=detail&aid=2906878&group_id=66150&atid=513503 -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
On Wed, Dec 2, 2009 at 5:06 PM, Marius Gedminas wrote: > On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote: >> Here's another idea: a testrunner option that takes a file name and line >> number and inserts a breakpoint at that position. That way you can get >> the same effect as editing the code without actually having to do so. > > Is that possible? I once spent hours studying pdb docs and found no way > to set a breakpoint in advance, without modifying the source file in > question, and without having the user to do manual interaction at the > beginning. I was envisioning using sys.settrace() to set a trace function that would notice when the desired line of code is being executed and then trigger pdb. I didn't plan on pdb doing the breakpoint handling itself. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote: > Here's another idea: a testrunner option that takes a file name and line > number and inserts a breakpoint at that position. That way you can get > the same effect as editing the code without actually having to do so. Is that possible? I once spent hours studying pdb docs and found no way to set a breakpoint in advance, without modifying the source file in question, and without having the user to do manual interaction at the beginning. The closest that I can come is import pdb dbg = pdb.Pdb() dbg.set_break(filename, lineno) dbg.runcall(entry_point) but this breaks into the pdb prompt at once, without waiting for the breakpoint to get triggered, and I have to manually 'c' to get unstuck. What am I missing? Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Patterson wrote: > Tres Seaver writes: > >> Are you using try:...finally:... inside your testcase methods? If so, >> why not just move the cleanup invocation into your 'tearDown' for the >> testcase class: at that point, the '-D' option to the testrunner will >> stop you at the error, with the tearDown not yet called. > > I'm sorry, I was unclear, the try/finally clauses are not necessarily in > *test tearDown* methods (though I used that language), they are often a > part of the application being tested, such as closing the request, > closing DB connections, or aborting transactions. OK. In such cases, I usually add a 'pdb.set_trace' to the testcase just before calling into the application-under-test, and step in from there. >> Or are you doing this in doctests? If so, move the code you are testing >> into a real testing framework. ;) > > Oh, goody. Derogatory evangelism. :) Doctests have tearDown just like > other tests. The teardown for doctests runs at the end of the entire text file, which is far too late for the kind of granular teardown needed to maintain proper test isolation. Because of this granularity, people sometimes inline 'try:...finally:...' into the body of the tests, trying to achieve some isolation / cleanliness. Doctests don't work for thorough unit testing: trying to make them substitue for unit tests just ruins any value they have as documentation. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksWu+0ACgkQ+gerLs4ltQ5VZgCg0PljroCmLWSO/jjx7dUTu4sj Af8AoID1nhnnzzqtvqNZUwo5FO4YmPtU =4Zx2 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
Benji York writes: > On Wed, Dec 2, 2009 at 1:22 PM, Ross Patterson wrote: >> I'm sorry, I was unclear, the try/finally clauses are not necessarily in >> *test tearDown* methods (though I used that language), they are often a >> part of the application being tested, such as closing the request, >> closing DB connections, or aborting transactions. > > In those situations I just edit the code and put a "import > pdb;pdb.set_trace()" at the top of the finally: block and re-run the > test. > > It is an interesting idea to provide some way to make that automatic. > Maybe a settrace hook that will invoke pdb at the top of every finally > clause that is encountered, somewhat similar to the -D option. You > might end up getting way too many false positives though. > > Here's another idea: a testrunner option that takes a file name and line > number and inserts a breakpoint at that position. That way you can get > the same effect as editing the code without actually having to do so. Or maybe a combination of the two where a configuration file is read for file and line numbers at which to do a post_mortem using a settrace hook where if the first one of those is hit no further post_mortem's are executed? Ross ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
On Wed, Dec 2, 2009 at 1:22 PM, Ross Patterson wrote: > I'm sorry, I was unclear, the try/finally clauses are not necessarily in > *test tearDown* methods (though I used that language), they are often a > part of the application being tested, such as closing the request, > closing DB connections, or aborting transactions. In those situations I just edit the code and put a "import pdb;pdb.set_trace()" at the top of the finally: block and re-run the test. It is an interesting idea to provide some way to make that automatic. Maybe a settrace hook that will invoke pdb at the top of every finally clause that is encountered, somewhat similar to the -D option. You might end up getting way too many false positives though. Here's another idea: a testrunner option that takes a file name and line number and inserts a breakpoint at that position. That way you can get the same effect as editing the code without actually having to do so. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
On Wed, Dec 02, 2009 at 09:08:51AM -0800, Ross Patterson wrote: > When a try/finally clause is (appropriately) used to do cleanup after an > exception during a test run, it often tears down parts of the fixture > that are needed in order to do useful post_mortem debugging of the > exception, such as closing the request or db connections. What is the > best way to do post_mortem debugging with the stack in the state it was > at the time of the exception? What I always do is find the line of code that raises the exception and wrap it with try: ... except: import pdb; pdb.set_trace() which is more or less exactly what you do: > For a while now, I've been repeatedly modifying eggs in my development > environment at the relevant try/finally clauses to invoke post_mortem > before the tear down is done, sub-optimal to say the least. :) I find > myself doing it often its time to invest in a better way. Worst part is when you use a shared buildout egg cache and forget to undo your experimental changes. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
Tres Seaver writes: > Ross Patterson wrote: >> When a try/finally clause is (appropriately) used to do cleanup after an >> exception during a test run, it often tears down parts of the fixture >> that are needed in order to do useful post_mortem debugging of the >> exception, such as closing the request or db connections. What is the >> best way to do post_mortem debugging with the stack in the state it was > >> at the time of the exception? >> >> For a while now, I've been repeatedly modifying eggs in my development >> environment at the relevant try/finally clauses to invoke post_mortem >> before the tear down is done, sub-optimal to say the least. :) I find >> myself doing it often its time to invest in a better way. >> >> Is there some Python voodoo I'm unaware of to get a post_mortem to >> reflect the stack before try/finally clauses? If not, is putting >> some sort of hook into the relevant try/finally clauses the best way to >> address this? If not, what should I be doing? >> >> If putting hooks into the try/finally clauses is the right way, then it >> would be nice to have a somewhat canonical way to do this. It would >> also be nice to have a way to pass something down the line so that >> post_mortem() only gets called once per exception. > > Are you using try:...finally:... inside your testcase methods? If so, > why not just move the cleanup invocation into your 'tearDown' for the > testcase class: at that point, the '-D' option to the testrunner will > stop you at the error, with the tearDown not yet called. I'm sorry, I was unclear, the try/finally clauses are not necessarily in *test tearDown* methods (though I used that language), they are often a part of the application being tested, such as closing the request, closing DB connections, or aborting transactions. > Or are you doing this in doctests? If so, move the code you are testing > into a real testing framework. ;) Oh, goody. Derogatory evangelism. :) Doctests have tearDown just like other tests. Ross ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Patterson wrote: > When a try/finally clause is (appropriately) used to do cleanup after an > exception during a test run, it often tears down parts of the fixture > that are needed in order to do useful post_mortem debugging of the > exception, such as closing the request or db connections. What is the > best way to do post_mortem debugging with the stack in the state it was > at the time of the exception? > > For a while now, I've been repeatedly modifying eggs in my development > environment at the relevant try/finally clauses to invoke post_mortem > before the tear down is done, sub-optimal to say the least. :) I find > myself doing it often its time to invest in a better way. > > Is there some Python voodoo I'm unaware of to get a post_mortem to > reflect the stack before try/finally clauses? If not, is putting > some sort of hook into the relevant try/finally clauses the best way to > address this? If not, what should I be doing? > > If putting hooks into the try/finally clauses is the right way, then it > would be nice to have a somewhat canonical way to do this. It would > also be nice to have a way to pass something down the line so that > post_mortem() only gets called once per exception. Are you using try:...finally:... inside your testcase methods? If so, why not just move the cleanup invocation into your 'tearDown' for the testcase class: at that point, the '-D' option to the testrunner will stop you at the error, with the tearDown not yet called. Or are you doing this in doctests? If so, move the code you are testing into a real testing framework. ;) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksWrVkACgkQ+gerLs4ltQ4JbQCeOuA9k90+E/KF2HRTO1fy46B/ tPYAoJ3CKOfxu+Ty7a5Tystu/PL5iy9O =cSLA -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
When a try/finally clause is (appropriately) used to do cleanup after an exception during a test run, it often tears down parts of the fixture that are needed in order to do useful post_mortem debugging of the exception, such as closing the request or db connections. What is the best way to do post_mortem debugging with the stack in the state it was at the time of the exception? For a while now, I've been repeatedly modifying eggs in my development environment at the relevant try/finally clauses to invoke post_mortem before the tear down is done, sub-optimal to say the least. :) I find myself doing it often its time to invest in a better way. Is there some Python voodoo I'm unaware of to get a post_mortem to reflect the stack before try/finally clauses? If not, is putting some sort of hook into the relevant try/finally clauses the best way to address this? If not, what should I be doing? If putting hooks into the try/finally clauses is the right way, then it would be nice to have a somewhat canonical way to do this. It would also be nice to have a way to pass something down the line so that post_mortem() only gets called once per exception. Thoughts, Ross ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Chris McDonough wrote: > Thomas Lotze wrote: >> Martijn Faassen wrote: >> >>> * a utility never has a connection. That's because it already got >>> instantiated long before the lookup takes place. >> Isn't it the other way around: A utility never has a connection to any >> adapted object, and that's *why we can* instantiate it long before the >> lookup takes place. >> >> I think the difference between these two perspectives may have to do with >> why some people in this discussion confuse (as I see it) the concepts of >> instance vs. factory registration and adapter vs. utility lookup. > > I'm not confused. I understand this worldview. > > I'm just arguing that this worldview is less understandable for new users and > maintenance programmers than it would be to leave them distinct (or to > "unify" > them by providing an API like "lookup" which never calls the result of an > adaptation). The conceptual beauty of how they might be otherwise similar is > meaningless to new users and maintenance programmers. ... and possibly hostile to people who've educated themselves about the current patterns and nomenclature. Anyway, I get the feeling we've moved on, and that this issue is eclipsing the more worthwhile discussion about API design and consistency, which I think we all want. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Wednesday 02 December 2009, Lennart Regebro wrote: > When there is such a clear and distinct conceptual difference between > adapters and utilities, why would we try to murk that distinction by > pretending that non adapters are a special case of adapters, when it's > obvious that that's exactly what they are not. "Null-adaptation" is a > contradiction in terms. It requires adapters that does not adapt. It > can only lead to complete confusion. I concur. There is no point in merging the concepts of adapters and utilities, since they are fundamentally different. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Unifying adapters and utilities gets us nowhere. If we remove the distinction between an adapter and a utility we are simply left with the concept of "component". Then we have components, nothing else. Components are objects registered base on what interface they implement, and can be looked up based on that interface. But then in the registration we have two types of components. Those who simply implement an interface, nothing more. Then we have those who implement and interface and also adapts one or more interfaces to the implemented interface. Well... then we have adapters again! So the unification quickly exploded. Conceptually we have components that adapt, and therefore clearly are adapters, and we have components that do not adapt, and therefore are not adapters. Currently we call those components utilities. When there is such a clear and distinct conceptual difference between adapters and utilities, why would we try to murk that distinction by pretending that non adapters are a special case of adapters, when it's obvious that that's exactly what they are not. "Null-adaptation" is a contradiction in terms. It requires adapters that does not adapt. It can only lead to complete confusion. The ZCA is hard enough as it is to understand. This discussion was about making it easier. If we want that, we can not unify adapters and utilities in the public API. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Gary Poster wrote: > Without this distinction, AFAICT either you want to conflate the ideas, or > you have a concept of the differences between the two that is more > esoteric than I think is useful. I get the impression that it is on the > second point of those that we disagree. Right, I understand the motivation behind your arguments, and I do have a different opinion. OTOH, it's probably helpful for the discussion to have spelled this disagreement out. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Dec 2, 2009, at 8:58 AM, Fred Drake wrote: > On Wed, Dec 2, 2009 at 8:42 AM, Gary Poster wrote: >> You are arguing for the unification of utilities and adapters? > > No. I'm arguing not to conflate utilities with the singleton pattern > or adaptation with ownership of the resulting adaptation. OK. I have given up on the singleton presentation. I still think that it has as much validity as comparing adaptation to type casting, but let's leave it. It's dead. The "ownership" issue is just a small part of the larger picture that I address below. On Dec 2, 2009, at 9:19 AM, Thomas Lotze wrote: > I think the difference between these two perspectives may have to do with > why some people in this discussion confuse (as I see it) the concepts of > instance vs. factory registration and adapter vs. utility lookup. It's not a matter of confusion in my mind. It's a matter of trying to present these ideas in a way that people who do not use these ideas frequently understand and remember easily. I think the difference is between the perspective of people who use these tools day in and out, and are already comfortable with them; and the perspective of people who want to make the ideas easy to use and remember for introductory and casual/intermittent usage. If Python presented classes as abstract callables that can do whatever the heck you want, I don't think that would be particularly useful. That's what they are, but we mostly use them as factories. They are generally explained as factories. The exceptions are that: unusual exceptions to the rule and basic idea. Instance vs. factory registration is a clean way of distinguishing between "utilities" and "adapters". "adapters" is IMO not an accurate description of how we use "multiadapters" (and certainly not "subscription adapters," which is another whole ball of wax that has a different solution IMO). Without this distinction, AFAICT either you want to conflate the ideas, or you have a concept of the differences between the two that is more esoteric than I think is useful. I get the impression that it is on the second point of those that we disagree. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Thomas Lotze wrote: > Martijn Faassen wrote: > >> * a utility never has a connection. That's because it already got >> instantiated long before the lookup takes place. > > Isn't it the other way around: A utility never has a connection to any > adapted object, and that's *why we can* instantiate it long before the > lookup takes place. > > I think the difference between these two perspectives may have to do with > why some people in this discussion confuse (as I see it) the concepts of > instance vs. factory registration and adapter vs. utility lookup. I'm not confused. I understand this worldview. I'm just arguing that this worldview is less understandable for new users and maintenance programmers than it would be to leave them distinct (or to "unify" them by providing an API like "lookup" which never calls the result of an adaptation). The conceptual beauty of how they might be otherwise similar is meaningless to new users and maintenance programmers. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Martijn Faassen wrote: > * a utility never has a connection. That's because it already got > instantiated long before the lookup takes place. Isn't it the other way around: A utility never has a connection to any adapted object, and that's *why we can* instantiate it long before the lookup takes place. I think the difference between these two perspectives may have to do with why some people in this discussion confuse (as I see it) the concepts of instance vs. factory registration and adapter vs. utility lookup. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Wed, Dec 2, 2009 at 8:42 AM, Gary Poster wrote: > You are arguing for the unification of utilities and adapters? No. I'm arguing not to conflate utilities with the singleton pattern or adaptation with ownership of the resulting adaptation. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Gary Poster wrote: > > On Dec 2, 2009, at 8:33 AM, Fred Drake wrote: > >> On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze wrote: >>> To be honest, I just don't see why this whole singleton business >>> shouldn't be orthogonal to the concepts of the component architecture. >> >> Well said. If an application cares about singleton creation or >> ownership of factory-returned objects, it can describe those >> requirements using interfaces. > > You are arguing for the unification of utilities and adapters? IMO we're arguing that singletons, the registration of instances vs factories and the distinction between utilities and adapters are three completely different subjects that are orthogonal to each other. I.e. I consider all eight of these combinations conceivable: take a class that may or may not implement a singleton and register an instance of it or the class itself as an adapter or a utility. (I do agree that an adapter being a singleton is a pathological case but I wouldn't consider it conceptually unthinkable.) -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Dec 2, 2009, at 8:33 AM, Fred Drake wrote: > On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze wrote: >> To be honest, I just don't see why this whole singleton business shouldn't >> be orthogonal to the concepts of the component architecture. > > Well said. If an application cares about singleton creation or > ownership of factory-returned objects, it can describe those > requirements using interfaces. You are arguing for the unification of utilities and adapters? Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze wrote: > To be honest, I just don't see why this whole singleton business shouldn't > be orthogonal to the concepts of the component architecture. Well said. If an application cares about singleton creation or ownership of factory-returned objects, it can describe those requirements using interfaces. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Tue Dec 1 12:00:00 2009 UTC to Wed Dec 2 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Dec 1 20:38:19 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013119.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Dec 1 20:40:19 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013120.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 1 20:42:19 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013121.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 1 20:44:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013122.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 1 20:46:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013123.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 1 20:48:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013124.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests fail
Christian Zagrodnick wrote: > On 2009-12-01 16:36:50 +0100, yuppie said: >> Christian Zagrodnick wrote: >>> AttributeError: 'NoneType' object has no attribute 'location' >> Should be fixed now. Yuppie > > Thanks! And it was such an easy fix! :) Well. Actually I didn't test with a clean buildout and removed 'zope.contenttype' as well because it wasn't part of my dependencies. But you noticed and fixed that already :) Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
