Skip to content

Conversation

@janverb
Copy link
Contributor

@janverb janverb commented Dec 19, 2019

This brings the stubs more in line with the Python 3 stubs and matches the implementation.

TextTestRunner.run is mentioned a few times in the docs but it's not listed separately so I think it's technically undocumented.

Copy link
Collaborator

@srittau srittau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, a few remarks below.

def __init__(self, stream: TextIO, descriptions: bool, verbosity: int) -> None: ...
def getDescription(self, test: TestCase) -> str: ... # undocumented
def printErrors(self) -> None: ... # undocumented
def printErrorList(self, flavour: str, errors: List[Tuple[TestCase, str]]) -> None: ... # undocumented
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the implementation, we can use Iterable instead of List here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation calls it with TestResult.errors (List) as an argument. Making it List allows implementations in subclasses to assume the argument is a list, which I think is more useful given that it's routinely called by printErrors and there's not much reason to call it from the outside.

Optional[BaseException],
Optional[types.TracebackType]]

class Testable(metaclass=ABCMeta):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we even need this class? It does not exist in the implementation and I don't really know what purpose it serves in the stubs, especially now that you removed its uses.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It effectively means Union[TestCase, TestSuite]. I didn't remove all uses, just the ones that I noticed should be TestCase instead.

It shouldn't be a class, but changing that would take a lot more work.


_SysExcInfoType = Tuple[Optional[Type[BaseException]],
Optional[BaseException],
Optional[types.TracebackType]]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make more sense to use Union[Tuple[None, None, None], Tuple[Type[BaseException], BaseException, types.TracebackType]]?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, that matches sys.exc_info(). I copied it from the Python 3 stubs, I'll change it there too.

@srittau srittau merged commit a705d59 into python:master Dec 19, 2019
@rchen152
Copy link
Collaborator

rchen152 commented Jan 9, 2020

I'm trying to import a new version of typeshed into Google, and this change is causing new type errors in Python 2. What's happening is that we have code calling TestResult.addUnexpectedSuccess(<instance of FunctionTestCase>), which now fails to type check because addUnexpectedSuccess and friends were changed to accept TestCase instead of Testable.

In the unittest implementation, FunctionTestCase is a subclass of TestCase: https://github.com/python/cpython/blob/249706c1fbce04125d81bd9993e6c010ae30f8e4/Lib/unittest/case.py#L1019.

In unittest.pyi, FunctionTestCase and TestCase both subclass Testable. (I'm guessing this choice was made because the documentation says that FunctionTestCase implements only a portion of the TestCase interface: https://docs.python.org/2/library/unittest.html#unittest.FunctionTestCase.)

It seems to me that the type definition of TestResult.addUnexpectedSuccess has been changed to follow the implementation, but the type definitions intentionally differ slightly from the implementation, so we should either (1) change the function signature to accept Testable again or (2) make FunctionTestCase inherit from TestCase. Thoughts?

@JelleZijlstra
Copy link
Member

(2) sounds right to me; if it inherits from TestCase at runtime the stub should also inherit from TestCase.

@rchen152
Copy link
Collaborator

rchen152 commented Jan 9, 2020

Sounds good, I'll make a PR.

rchen152 added a commit that referenced this pull request Jan 9, 2020
This makes the pyi file match the implementation:
https://github.com/python/cpython/blob/249706c1fbce04125d81bd9993e6c010ae30f8e4/Lib/unittest/case.py#L1019.

I also removed a now-redundant `run` method from FunctionTestCase
because the mypy test complained about it having a different signature
from TestCase.run().

Context:
#3550 (comment).
JelleZijlstra pushed a commit that referenced this pull request Jan 9, 2020
)

This makes the pyi file match the implementation:
https://github.com/python/cpython/blob/249706c1fbce04125d81bd9993e6c010ae30f8e4/Lib/unittest/case.py#L1019.

I also removed a now-redundant `run` method from FunctionTestCase
because the mypy test complained about it having a different signature
from TestCase.run().

Context:
#3550 (comment).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants