[Python-Dev] Question over splitting unittest into a package

Benjamin Peterson benjamin at python.org
Wed Dec 30 21:04:31 CET 2009


2009/12/30 Martin (gzlist) <gzlist at googlemail.com>:
> Hi Benjamin,

Hi!

>
> In rev 74094 of Python, you split the unittest module up, could you
> point me at any bug entries or discussion over this revision so I can
> catch up?

This was mostly a discussion on IRC between Michael Foord and myself.

>
> As a side-effect you seem to have changed the method of marking a
> module as not worth including in a traceback to be no longer
> extensible.
>
> Before:
> <http://svn.python.org/view/python/trunk/Lib/unittest.py?view=markup&pathrev=74094>
>
> A global was set at the top of the module:
>
>    __unittest = 1
>
> Which is then checked for when constructing traceback output:
>
>    def _is_relevant_tb_level(self, tb):
>        return '__unittest' in tb.tb_frame.f_globals
>
> After:
> <http://svn.python.org/view/python/trunk/Lib/unittest/__init__.py?revision=74095&view=markup>
>
>    def _is_relevant_tb_level(self, tb):
>        globs = tb.tb_frame.f_globals
>        is_relevant =  '__name__' in globs and \
>            globs["__name__"].startswith("unittest")
>        del globs
>        return is_relevant
>
> Only packages actually named "unittest" can be excluded.
>
> What is now the prefered method of marking a module as test-internal?
> Overriding the leading-underscore _is_relevant_tb_level method? How
> can this be done cooperatively by different packages?

When I made that change, I didn't know that the __unittest "hack" was
being used elsewhere outside of unittest, so I felt fine replacing it
with another. While I still consider it an implementation detail, I
would be ok with exposing an "official" API for this. Perhaps
__unittest_ignore_traceback?


> I would have CCed a mailinglist with this question but don't like
> getting yelled at for posting on the wrong one, please feel free to do
> so with your reply if you feel it's appropriate (the CCing, not the
> yelling).

python-dev is perfect for this discussion.


-- 
Regards,
Benjamin


More information about the Python-Dev mailing list