I dont understand your intention with these tasks.

Do you mean that repr(page).decode('ascii') should not cause UnicodeDecodeError ?

If so, I would like a more detailed explanation of why it should not cause UnicodeDecodeError.

This certainly can be explained better in the test, but despite many many efforts, this is the best repr that we can build that does the 'right' thing in as many cases as possible.

As the comment in this test says "Bug T95809, the repr in Python 2 should be decodable as ASCII"

The output of repr should be ASCII on Python 2, according to the spec , however the Python 2 console accepts bytes in the console encoding, so we give it bytes in the console encoding which means unicode characters are displayed correctly. If repr must return ASCII, then non-ASCII must be downgraded to ASCII somehow, which isnt pretty.

IMO this is exactly what expectedFailure is designed for, and I've presented my opinion supporting their use at T129368#2153128 , where we can continue that debate.

The test is described as

"""Test that repr returns ASCII compatible bytes in Python 2."""

and

\# Bug T95809, the repr in Python 2 should be decodable as ASCII

but the test fails, which means it is not decodable:

>>> repr(p).decode('ascii')

Traceback (most recent call last):
  File "<pyshell#29>", line 1, in <module>
    repr(p).decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 5: ordinal not in range(128)
>>>

Either the test is wrong or the description is wrong.

In T130919#2153737, @Xqt wrote:

The test is described as

"""Test that repr returns ASCII compatible bytes in Python 2."""

and

\# Bug T95809, the repr in Python 2 should be decodable as ASCII

but the test fails, which means it is not decodable:

>>> repr(p).decode('ascii')

Traceback (most recent call last):
  File "<pyshell#29>", line 1, in <module>
    repr(p).decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 5: ordinal not in range(128)
>>>

Either the test is wrong or the description is wrong.

Yes, the test description is 'wrong'. The method is testing what should succeed, and that is what is described in the docstring. But of course it fails and expectedFailure checks that it fails. That is confusing.

If we built the repr according to the spec, it would pass. But building it according to the spec means that repr wont be pretty in a python console session. The code, from before 2014 and still now, chose to use non-ascii repr as opposed to ascii repr. @XZise was very opposed this, and tried to switch to ascii repr. I believe we should stay with non-ascii repr, mostly because both approaches have negatives, and the only way to avoid all negatives is to use Python 3.

Do you want ascii repr?

If not, then I can expand this docstring so it isnt confusing and then this task is done?

Change 608690 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [tests] Remove failing test_ASCII_compatible test

https://gerrit.wikimedia.org/r/c/pywikibot/core/ /608690

Change 608690 merged by jenkins-bot:
[pywikibot/core@master] [tests] Remove failing test_ASCII_compatible test

https://gerrit.wikimedia.org/r/c/pywikibot/core/ /608690