[Zope3-dev] Re: Zope3/src/zope/app/browser/skins/debug/exceptions.py:1.1

[Tres Seaver]

On Wed, 2003-03-12 at 04:49, Steve Alexander wrote:
> Hi Tres,
> 
> This looks like a very useful feature, and I'm sure I'll be glad of it.
> 
>    http://mail.zope.org/pipermail/zope3-checkins/2003-March/006940.html
> 
> I've been staring at stderr on the console to understand errors, 
> recently, which has certain distracting disadvantages.

It is especially bad when the error reporting service breaks, as
happened to me due to renaming activity over the weekend.

> I have a suggestion, a query, and a negative comment about the checkin.
> 
> 
> The suggestion:
> 	
>    There's an exceptionformatter module that you might want to use:
> 
>    from zope.exceptions.exceptionformatter import format_exception
>    t, v, tb = sys.exc_info()
>    try:
>        self.traceback = ''.join(format_exception(t, v, tb, as_html=1))
>    finally:
>        tb = None

Hmm, it doesn't feel right to me to have the view class do the
"templating" bit in its __init__.  Perhaps it should just make
that service available to the template?

> The query:
> 
>    I'm pretty sure that __used_for__ has been a single interface,
>    not a tuple of interfaces. Was there a particular reason you used
>    a tuple?

Nope.  I think I saw it that way someplace, but could be wrong.  I
thought of it as syntactically similar to __implements__.

>    Then again, __used_for__ isn't being used anywhere in particular
>    just now, and I've been omitting it from views and adapters
>    recently.
>    I'd like to work on a more general component specification 'something'
>    at some point...
> 
> 
> The negative comment:
> 
>    The code formatting style that has been generally agreed for Zope 3
>    is here:
> 
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CodingStyle
> 
>    It defers to PEP 8 on most issues.
> 
>      http://www.python.org/peps/pep-0008.html
> 
>    [Don't use whitespace...]
> 
>      - Immediately inside parentheses, brackets or braces, as in:
>        "spam( ham[ 1 ], { eggs: 2 } )".  Always write this as
>        "spam(ham[1], {eggs: 2})".
> 
> 
>    Most Zope 3 code has docstrings that go:
> 
>      class Foo:
>          """This is the docstring for Foo.
>          """
> 
>          someCodeInTheClassSuite = Bar()
> 
>    rather than:
> 
>      class Foo:
> 
>          """ This is the docstring for Foo.
>          """
>          someCodeInTheClassSuite = Bar()

I don't *like* those style choices much, but I intend to abide by them
inside the Zope3 corpus.  I moved the module from an add-on product I am
working on, and forgot to fix up the formatting.

>    Classes in Zope 3 should usually be new-style classes rather
>    than classic classes. This is usually done using
> 
>      __metaclass__ = type
> 
>    at the module level.
>
>    This is important for views, as the code that sets up views from zcml
>    directives sometimes does some fancy things that only work properly
>    with new-style classes.

Cool.  I've seen that, but didn't know when / why to follow suit.

>    The exceptions.py module that you checked in has no unit test.
>    It must have at least a minimal unit test that raises an exception,
>    creates an instance of ExceptionDebugView, and checks that
>    theview.traceback_lines exists, and contains some text.
>    Right now, I could accidentally introduce a syntax error into the
>    view code, and it would not be caught by a unit test. Let alone,
>    more subtle errors.

I hadn't considered that the module was doing anything testable, and was
looking at the content of the other two skin directories when I built
'debug'.  Neither of '{rotterdam,zopetop}/standardmacros.py' has tests
(but they don't do much interesting, either).

> I'm pretty keen on keeping the coding style consistent. I believe that 
> it helps slightly with experienced developers reading and maintaining 
> the code, and a lot with inexperienced developers reading and 
> understanding the code.

> Do you mind if I alter your code to conform to this style?

Nope.  I see you made a start;  I'll normalize the whitespace, and add
a minimal test.

> I'm very keen that every module checked in should have a minimal unit 
> test, at the very least.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com