From: Felix W. <Fel...@gm...> - 2004-06-22 21:40:47
|
~/source/docutils/docutils/test $ python2.1 test_functional.py .. ---------------------------------------------------------------------- Ran 2 tests in 9.977s OK ~/source/docutils/docutils/test $ python2.1 alltests.py Testing Docutils 0.3.4 with Python 2.1.3 Tests of docutils.readers.python skipped; Python 2.2 or higher required. .........................................................................................................................FF........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ ====================================================================== FAIL: Functional test for functional/tests/standalone_rst_html4css1.py ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/home/felix/source/docutils/docutils/test/test_functional.py", line 123, in test self.assertEqual(output, expected, diff) File "/usr/lib/python2.1/unittest.py", line 273, in failUnlessEqual raise self.failureException, (msg or '%s != %s' % (first, second)) AssertionError: Functional test failed. Please compare the following files: functional/expected/standalone_rst_html4css1.html functional/output/standalone_rst_html4css1.html ====================================================================== FAIL: Functional test for functional/tests/standalone_rst_latex.py ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/home/felix/source/docutils/docutils/test/test_functional.py", line 123, in test self.assertEqual(output, expected, diff) File "/usr/lib/python2.1/unittest.py", line 273, in failUnlessEqual raise self.failureException, (msg or '%s != %s' % (first, second)) AssertionError: Functional test failed. Please compare the following files: functional/expected/standalone_rst_latex.tex functional/output/standalone_rst_latex.tex ---------------------------------------------------------------------- Ran 723 tests in 34.362s FAILED (failures=2) Elapsed time: 37.192 seconds ~/source/docutils/docutils/test $ diff -U 3 functional/expected/standalone_rst_html4css1.html functional/output/standalone_rst_html4css1.html --- functional/expected/standalone_rst_html4css1.html 2004-06-22 23:13:20.000000000 +0200 +++ functional/output/standalone_rst_html4css1.html 2004-06-22 23:35:46.000000000 +0200 @@ -14,7 +14,7 @@ <meta name="copyright" content="This document has been placed in the public domain. You may do with it as you wish. You may copy, modify, redistribute, reattribute, sell, buy, rent, lease, destroy, or improve it, quote it at length, excerpt, incorporate, collate, fold, staple, or mutilate it, or do anything else to it that your or anyone else's heart desires." /> <meta content="reStructuredText, test, parser" name="keywords" /> <meta content="A test document, containing at least one example of each reStructuredText construct." lang="en" name="description" /> -<link rel="stylesheet" href="default.css" type="text/css" /> +<link rel="stylesheet" href="../../data/stylesheets/default.css" type="text/css" /> </head> <body> <h1 class="title">reStructuredText Test Document</h1> @@ -744,5 +744,11 @@ Duplicate target name, cannot be used as a unique reference: "duplicate target names".</div> </div> </div> +<hr class="footer" /> +<div class="footer"> +<a class="reference" href="../input/standalone_rst_html4css1.txt">View document source</a>. +Generated on: 2004-06-22 21:35 UTC. +Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source. +</div> </body> </html> Same for the LaTeX output. It only happens when running alltests.py with Python 2.1. Any ideas what's it because of? -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. <http://www.ososo.de/> |
From: Felix W. <Fel...@gm...> - 2004-06-22 22:24:44
|
Felix Wiemann wrote: > ~/source/docutils/docutils/test $ python2.1 alltests.py > Testing Docutils 0.3.4 with Python 2.1.3 > Tests of docutils.readers.python skipped; Python 2.2 or higher required. > .........................................................................................................................FF........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ After re-checking-out the Docutils tree, the functional tests were executed at the beginnung (as I could see from the high execution time for the first dots). There they didn't fail. So it seems to have to do with the order in which the tests are executed. I'll go to bed now. Maybe tomorrow I'll do some further investigation on that bug. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. <http://www.ososo.de/> |
From: David G. <go...@py...> - 2004-06-22 22:31:35
|
Felix Wiemann wrote: > Same for the LaTeX output. It only happens when running alltests.py > with Python 2.1. > > Any ideas what's it because of? Part of it is probably because the default config file processing is being done, picking up your ~/.docutils file or a local docutils.conf. DocutilsTestSupport.py's WriterPublishTestCase class disables config file processing by being a subclass of docutils.SettingsSpec and including this code: settings_default_overrides = {'_disable_config': 1} For this to work, the test_publish method has to pass ``settings_spec=self`` to docutils.core.publish_string (publish_file in test_functional.py's case). Try that, and if any other bug is left, we'll take a look. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2004-06-25 12:11:10
|
David Goodger wrote: > Part of it is probably because the default config file processing is > being done, picking up your ~/.docutils file or a local docutils.conf. > DocutilsTestSupport.py's WriterPublishTestCase class disables config > file processing by being a subclass of docutils.SettingsSpec and > including this code: > > settings_default_overrides = {'_disable_config': 1} > > For this to work, the test_publish method has to pass > ``settings_spec=self`` to docutils.core.publish_string (publish_file > in test_functional.py's case). I see, but I don't actually understand. I don't find any documentation on how the settings processing works. So I'd like to ask a few questions: What's the difference between settings, settings_spec and settings_overrides? Why do we need *three* 'settings' parameters instead of one? Why can't config file processing be deactivated by adding '_disable_config': 1 to settings_overrides? And why does the test case have to be a subclass of SettingsSpec? That looks *really* ugly, IMO. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. <http://www.ososo.de/> |
From: David G. <go...@py...> - 2004-06-25 22:13:41
|
Felix Wiemann wrote: > I see, but I don't actually understand. I don't find any > documentation on how the settings processing works. There's some in the docstrings: in docutils/frontend.py in OptionParser (esp. its populate_from_components method); and in docutils/__init__.py in SettingsSpec. But it's not comprehensive. Another one for the to-do list. This message will be a good start. > What's the difference between settings, settings_spec and > settings_overrides? Let's start with ``SettingsSpec`` subclasses (components: Readers, Parsers, Writers). They have several settings-related attributes: * ``settings_spec``: data that defines settings, processed by docutils.frontend.OptionParser, which it populates. * ``settings_defaults``: provides defaults for settings not in ``settings_spec`` (internal settings, intended to be inaccessible by command-line and config file). * ``settings_default_overrides``: overrides defaults defined in other components; it's applied later in the process. The docutils.core.publish_* functions have several parameters: * ``settings`` is an optparse.Values object, for dotted-attribute access to runtime settings. It's the end result of the settings spec, config file, and option processing. If ``settings`` is passed to a publish_* convenience function, it's assumed to be complete and no further setting/config/option processing is done. * ``settings_spec`` is a docutils.SettingsSpec subclass or object. It's used to define application-specific settings independently of components. In other words, the application becomes a component, and its settings data is processed along with that of the other components. * ``settings_overrides`` is a dictionary of application-specific settings defaults that override the defaults of other components. It's the runtime equivalent of the ``settings_default_overrides`` attribute of SettingsSpec subclasses (``settings_overrides`` is applied after SettingsSpec.settings_default_overrides). > Why do we need *three* 'settings' parameters instead of one? It's a mechanism for overlaying default & specified values such that settings work the way we want them to, with config files and command-line options. Here's how it works for command-line tools: 1. A docutils.core.Publisher object's publish method calls self.process_command_line, which calls self.setup_option parser, which creates a docutils.frontend.OptionParser object. The three regular components, self.parser, self.reader, and self.writer, plus the ``settings_spec`` parameter, are passed as ``components``. At the same time, docutils.core.Publisher.publish passes ``settings_overrides`` on to self.process_command_line as ``defaults``, which is then passed on to self.setup_option_parser, then on to docutils.frontend.OptionParser's __init__. So, docutils.frontend.OptionParser.__init__ receives these two parameters from the docutils.core.Publisher object: * components: (self.parser, self.reader, self.writer, settings_spec) * defaults: settings_overrides 2. docutils.frontend.OptionParser.__init__ calls self.populate_from_components with self.components, which consists of ``self`` prepended to the list of components it received. ``self`` (docutils.frontend.OptionParser) defines general Docutils settings. 3. In docutils.frontend.OptionParser.populate_from_components, for each component passed, component.settings_spec and component.settings_defaults are processed. Then, for each component, component.settings_default_overrides is processed. This two-loop process ensures that component.settings_default_overrides can override the default settings of any other component. 4. docutils.frontend.OptionParser.__init__ overlays its ``defaults`` parameter (derived from the Publisher.publish ``settings_overrides`` parameter) over self.defaults. So ``settings_overrides`` has priority over all SettingsSpec data. 5. OptionParser.__init__ checks if configuration files are enabled (``read_config_files`` parameter is True, and self.defaults['_disable_config'] is False). If they are enabled (and normally, they are), self.get_standard_config_settings is called, returning a dictionary of settings from the config file(s). This is overlaid on self.defaults. So config file settings have priority over ``settings_overrides`` and SettingsSpec data. > Why can't config file processing be deactivated by adding > '_disable_config': 1 to settings_overrides? With a change in the implementation logic, now you can! And I did! I took a look at the code, and couldn't figure out why it was that way (probably historical only), so I fixed it. I'm pretty certain it's correct, but I may be wrong. We'll find out soon enough ;-) > And why does the test case have to be a subclass of SettingsSpec? It doesn't have to any more. It did before in order to enable the ``settings_default_overrides`` mechanism. > That looks *really* ugly, IMO. Why? Anyway, it's just test code, which is all pretty ugly. Who cares what it looks like? -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2004-06-27 20:05:50
|
David Goodger wrote: > Felix Wiemann wrote: > >> What's the difference between settings, settings_spec and >> settings_overrides? > > Let's start with ``SettingsSpec`` subclasses (components: Readers, > Parsers, Writers). [...] Thank you very much for your detailed explanations! >> Why can't config file processing be deactivated by adding >> '_disable_config': 1 to settings_overrides? > > With a change in the implementation logic, now you can! Great! >> And why does the test case have to be a subclass of SettingsSpec? >> That looks *really* ugly, IMO. > > Why? Because multiple inheritance from TestCase and SettingsSpec causes the class to represent two entirely unrelated objects. But your change to test_functional.py fixed this anyway, and now it looks much better. > Anyway, it's just test code, which is all pretty ugly. It doesn't have to be. > Who cares what it looks like? I do, for example. And probably most people who want to read other people's test code. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. <http://www.ososo.de/> |
From: David G. <go...@py...> - 2004-06-27 20:56:39
|
Felix Wiemann wrote: > Thank you very much for your detailed explanations! You're welcome. Please note that I've expanded upon that message and added a "Docutils Runtime Settings" document to the project: http://docutils.sf.net/docs/api/ It's not complete, but it's a start. Thanks for the nudge! You'll also note that I added a docs/api/ directory. It currently contains these new documents as well: * "The Docutils Publisher": http://docutils.sf.net/docs/api/publisher.html * "Inside A Docutils Command-Line Front-End Tool": http://docutils.sf.net/docs/api/cmdline-tool.html -- David Goodger <http://python.net/~goodger> |