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

[Steve Alexander]

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.


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


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?
   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()


   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.


   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'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?


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

--
Steve Alexander