[docs] [issue18576] Document test.support.script_helper

[Martin Panter]

Martin Panter added the comment:

If you diffed your patch from a public revision in the main repository, there should be a nice “Review” link. Anyway, here are some comments on issue18576.patch:

+.. function:: assert_python_ok(*args, **env_vars)
+
+   Runs the interpreter with *args* and optional environment
+   variables, asserting that *env_vars* succeeds (``rc == 0``).

Perhaps you mean *env_vars* are the optional environment variables, and that the interpreter is asserted to have succeeded.

Also maybe clarify where the *__cleanenv* and *__isolated* keywords come from? Function signatures? Also applies to assert_python_failure(), run_python/_until_end().

Maybe it is worth mentioning that assert_python_ok/failure() strip whitespace from the stderr stream. I seem to remember being tricked by this (writing a test to ensure stderr ended in a newline or something).

+   ``stdout`` are configured as binary pipes and ``stderr`` is merged with
+   ``stdout``..

There are two full stops above here..

I encourage you to start sentences with capital letters (although I admit sometimes other people do not agree with this). Suggestions:

+   *kw* is passed through to subprocess.Popen as additional keyword
+   arguments.
=> The *kw* arguments are passed through to subprocess.Popen.

+   *source* is a Unicode string which will be written to the file as UTF-8.
=> The *source* argument is a Unicode string which will be written to the file as UTF-8.

+   *depth* controls how many deeply nested the package is.
=> The *depth* argument controls how deeply nested the package is.

+   Creates a new zip archive in the given directory, containing the specified
+   Python script/module

Needs one of those full stops I mentioned earlier :)

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________