|
From: David G. <go...@py...> - 2002-11-13 01:29:24
|
eng...@ss... wrote:
> maybe some kind soul can have a look at it.
Checked in your initial copy plus some extensive changes (see below).
Thanks!
> it does get all docutils.languages (even en_US should work).
Great, we can add US slang! How about ".. contents-y'all::"? ;)
(Yes, I know a directive can't have a "'" in its name.)
I don't know if we'll ever need country/dialect codes, but in PEP 258
I defined the language codes as case-insensitive, so the module name
should actually be "en_us.py" (lower case).
> but i would like to setup a testcase per language so the
> test is not broken by the first error.
What is needed here is a dynamic, data-driven test suite. Most of the
Docutils test modules use the test/DocutilsTestSupport.py module for
this. I've modified the test_language.py code to use this framework,
dynamically creating a test (a TestCase object) for each language and
method.
> and this is my first try at unittest
You chose a challenge to begin with. I suggest you look at
test_nodes.py, test_statemachine.py, or test_utils.py for more typical
examples.
General tip: at the top of script files, don't use::
#!/usr/bin/python
Please use this instead::
#! /usr/bin/env python
The former is hard-coded. For example, it finds Python 1.5.2 on
RedHat. The latter finds an executable called "python" on the user's
path. I've set up my environment so Python 2.2 is found first. Some
people will have their Python interpreter at /usr/local/bin/python or
non-standard places.
--
David Goodger <go...@py...> Open-source projects:
- Python Docutils: http://docutils.sourceforge.net/
(includes reStructuredText: http://docutils.sf.net/rst.html)
- The Go Tools Project: http://gotools.sourceforge.net/
|