Skip to content

Conversation

blueyed
Copy link
Contributor

@blueyed blueyed commented Nov 4, 2019

No description provided.

Copy link
Member

@bluetech bluetech left a comment

Choose a reason for hiding this comment

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

I left some comments. Adding annotations to these tricky parts really helps!

truncate_locals: bool = True,
chain: bool = True,
):
) -> Union["ReprExceptionInfo", "ExceptionChainRepr"]:
Copy link
Member

Choose a reason for hiding this comment

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

Functions returning a Union are not great, because the caller must disambiguate which one they got.

In this case, both types share a common base class ExceptionRepr. If all the caller cares about is getting an ExceptionRepr from this function, I suggest using that instead. This will also be more future proof.

If however the distinction is important (not in this case AFAIU), I think it will be better to either use two overloads on style, Literal["long"] which only returns ExceptionChainRepr and Literal["native"] which only returns ReprExceptionInfo. Or just split the function to two.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the input.
I've tried to be as strict / verbose as possible, given the code around all this.
Will consider using ExceptionRepr then.

Copy link
Member

Choose a reason for hiding this comment

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

Not sure if you decided to keep it this way.

Other than this, LGTM.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, better have it (re)strict(ed) for now.

# Type ignored: see comment where fail.Exception is defined.
if excinfo.errisinstance(fail.Exception): # type: ignore
def _repr_failure_py(
self, excinfo: ExceptionInfo[Union[Failed, "FixtureLookupError"]], style=None
Copy link
Member

Choose a reason for hiding this comment

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

Are we sure only Failed and FixtureLookupError are possible 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.

That are the ones I've found - can be adjusted if needed?

Copy link
Member

Choose a reason for hiding this comment

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

It depends on what the intention of the function is - to accept only these two types, or to accept any ExceptionInfo[E].

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My intention is to being made aware if other types are used.
This should aid with refactoring / cleanup - my main motivation to add types here.

blueyed added a commit to blueyed/pytest that referenced this pull request Nov 4, 2019
Ref: pytest-dev#6129

Conflicts:
	.travis.yml
	src/_pytest/_code/code.py
self.outcome = outcome
self.longrepr = longrepr
self.result = result or []
self.result = result or [] # type: List
Copy link
Member

Choose a reason for hiding this comment

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

Do you what type of list it is?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

So can this be List[CallInfo]?

(btw, it's perfectly fine if you left it out because it's too much work to check, I'm just commenting in case you forgot to fill it in).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, CallInfo sets the result to the return value from the functions.
Can be List[Node] then, will change it.

@blueyed
Copy link
Contributor Author

blueyed commented Nov 5, 2019

Updated (987f912), then squashed (741f0fe).
Please approve it if it loooks ok, so I can merge it then.

@blueyed blueyed merged commit 0794289 into pytest-dev:features Nov 5, 2019
@blueyed blueyed deleted the typing branch November 5, 2019 17:29
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.

2 participants