On 11/14/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > Luke Arno wrote: > > -1 to the proposed spec > > > > On 11/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > > ... > >> Other Possibilities > >> ------------------- > >> > >> * You can just get the unwrapped application object and test it. > > > > +1, emphatically > > > > Let's encourage best practices, before we > > standardize specific workarounds. > > > > The unwrapped version of the object should also be > > made available for composition purposes, if it is > > intended for such. > > OK, then, you're going to have to justify that, because I don't think > it's best practice ;)
I don't know what "justify" means in this context but I will try to explain. > In particular, in many frameworks the presence of an exception catcher > is automatic and largely opaque to the user. Of course it doesn't > *have* to be opaque, but because this is the only case where it really > matters I don't see why it shouldn't be opaque -- it's not worth explaining. I don't see why it should be opaque. It is just as easy to explain as your environ flag. Plus it is simpler and more explicit. This is a common pattern: application user interface and application programming interface. Here is the external, friendly, error-hiding app that you run by itself in production. Here is the raw app that you test and plug into the back of some larger app. And there is no additional config data to manage. Hooray! ;) > It's not opaque to me, of course, and yet I never feel a need to unpack > the object this way, because the one reason I might have is satisfied > transparently, automatically, and reliably by this environment convention. > > Exception handling is something that is generally handled by some > particular pieces of software -- the exception catcher and test > frameworks. If they can agree on this, I don't see a reason anyone else > needs to think about it. If the exception catcher isn't being put between the app and the test framework, there is no problem to solve or think about. I prefer non-problems to clever solutions. ;) Cheers, - Luke _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
