Added doctest encoding command line option

[wheerd]

I added a command line option to specify the encoding of doctest (.txt/.rst) files.
This should fix the error described in #540 which I am also having on my windows machine.

[RonnyPfannschmidt]

at first glance i wonder if this shouldn't use unicode marked strings like u"..."

i believe the actual encoding can be a parametrize parameter, and we might want to add an exotic one just to be on the paranoid side

[wheerd]

That would break the code for Python 3.0 I guess because iirc it didn't have the unicode prefix anymore.

[RonnyPfannschmidt]

@wheerd python 3.3 added it back for more pleasant dual codebases

[coveralls]

Coverage increased (+0.0008%) to 92.713% when pulling d254c6b on wheerd:doctest-encoding into 36eb5b3 on pytest-dev:features.

[coveralls]

Coverage increased (+0.0008%) to 92.713% when pulling 929912d on wheerd:doctest-encoding into 36eb5b3 on pytest-dev:features.

[RonnyPfannschmidt]

i propose making those a format string adding u in front of it for py2, and leaving it out for py3
that way the output can be tested

[wheerd]

In Python 2, they will be formatted as escape sequences: u'\x84\x94\x81'. Probably I can just repr(value) to the files.

[nicoddemus]

I think this would be better off being a ini option instead:

1. If one has to use this option, then usually all doctest.txt files will have the same encoding (if the developers want to keep their sanity that is) so it makes sense to configure that in pytest.ini;
2. If really desired, one can use the -o option to override ini options in the command-line.
3. It is usually not a good idea to require users to pass certain command-line options to make the test suite pass, and in which case the users don't pass the correct option the test-suite will fail in mysterious ways;

[nicoddemus]

I think you could use @pytest.mark.parametrize on the tests to avoid repeating yourself. Something like (already incorporating my request to change to an ini option):

import pytest

@pytest.mark.parametrize('string, encoding', [
    (u'foo', 'ascii'),
    (u'üäö', 'latin1'),
    (u'üäö', 'utf-8'),
])
def test_encoding_latin1(testdir, string, encoding):
    """Test support for doctest_encoding option.
    """
    testdir.makeini("""
        [pytest]
        doctest_encoding={0}
    """.format(encoding))
    testdir._makefile(".txt", u"""
        >>> len(u'{0}')
        3
    """.format(string), encoding=encoding)

    result = testdir.runpytest()
    result.stdout.fnmatch_lines([
        '*1 passed*',
    ])

EDIT: fixed a comment left by accident

[nicoddemus]

Other than my comments, please add a CHANGELOG entry under New Features and add yourself to the CHANGELOG. 😁

[coveralls]

Coverage decreased (-0.03%) to 92.68% when pulling 1f62e5b on wheerd:doctest-encoding into 36eb5b3 on pytest-dev:features.

[nicoddemus]

Please update the docs to mention the doctest_encoding ini option instead.

[wheerd]

Sorry, forgot about that.

[nicoddemus]

The use of {} is not supported by py26 and is breaking the CI, please change that to {0}, {1}, etc.

[nicoddemus]

I think we're almost there, thanks again for the PR!

[nicoddemus]

One last thing, please add this:

You can specify the encoding that will be used for those doctest files
using the ``doctest_encoding`` ini option:

.. versionadded:: 3.1

.. code-block:: ini

To convey to the users that this is new and was added in 3.1.

[coveralls]

Coverage decreased (-0.03%) to 92.68% when pulling f8fef07 on wheerd:doctest-encoding into 36eb5b3 on pytest-dev:features.

[coveralls]

Coverage decreased (-0.03%) to 92.68% when pulling f8fef07 on wheerd:doctest-encoding into 36eb5b3 on pytest-dev:features.

[RonnyPfannschmidt]

lovely - this is shaping up, good work

[coveralls]

Coverage decreased (-0.03%) to 92.68% when pulling 2edfc80 on wheerd:doctest-encoding into 36eb5b3 on pytest-dev:features.

[nicoddemus]

The py27-expect failure in AppVeyor is unrelated so this is good to merge.

Thanks again @wheerd!