Use TYPE_CHECKING instead of False

[blueyed]

This allows for e.g. Jedi to infer types.

It was only used to support Python 3.5.0/3.5.1, where this is available
in typing_extensions.

Ref: davidhalter/jedi#1472

TODO:

• I'll rebase this (with changelog) after merging master after ci: Travis: Python 3.5.1 via Trusty #6440
• rebased on / blocked by Merge master into features #6458

[The-Compiler]

Makes me wonder how common 3.5.0/3.5.1 really are in the wild - do we need/want to support them still? Also see some previous discussion in #5751.

[blueyed]

Makes me wonder how common 3.5.0/3.5.1 really are in the wild - do we need/want to support them still? Also see some previous discussion in #5751.

I'd be ok with dropping support for it, but did not want to hold that back (also since we had issues/reports with < 3.5.2 before).
As per #5751 (comment) 3.5.2 appears to be used in Ubuntu LTS (which is OK).

[nicoddemus]

Unless keeping the support becomes too terrible, I would rather we wait until we drop 3.5 completely.

[nicoddemus]

Thanks!

Please only add the CHANGELOG entry as requested, after that feel free to merge once CI passes. 👍

[blueyed]

I'll rebase this (with changelog) after merging master after #6440.

[bluetech]

LGTM, as long as the dependency is only for Python<=3.5.1 it's fine by me :)

According to the PR description, this fixes jedi type inference. According to the linked issue, the jedi maintainer says they're going to stop supporting Python 3.5 in a few months. So things are going to break for these users anyway. But I guess they can always use an older jedi with newer pytest, so it's not a good reason to not fix the issue.

[blueyed]

@bluetech

According to the PR description, this fixes jedi type inference. According to the linked issue, the jedi maintainer says they're going to stop supporting Python 3.5 in a few months. So things are going to break for these users anyway. But I guess they can always use an older jedi with newer pytest, so it's not a good reason to not fix the issue.

The point of this is that Jedi will actually infer types (it skips if False, but not if TYPE_CHECKING). So it fixes it also for 3.5.2+ - hope that clears things up.

[RonnyPfannschmidt]

tbh, in addition i like the named constant better than the magic constant, lovely, thanks

[bluetech]

Searching the jedi repo for typing_extensions brings up nothing, so I assume that the module isn't important, only the name. If so, can we avoid the runtime dep and just use TYPE_CHECKING = False for the fallback? I think mypy will be happy with this.

[blueyed]

Ok, falls back to TYPE_CHECKING = False now.
(Jedi checks the name)

[blueyed]

@RonnyPfannschmidt

tbh, in addition i like the named constant better than the magic constant, lovely, thanks

Do you mean we should use TYPE_CHECKING = False in compat always?

[RonnyPfannschmidt]

@blueyed unless there is something making that a no go, i'd strongly prefer it over replicating it per file

[blueyed]

@RonnyPfannschmidt
We have from typing import TYPE_CHECKING there now (for >= 3.5.2), not TYPE_CHECKING = False.

Anyway, this is still affected by circular imports now, fixed by avoiding it there, instead of moving imports to methods:

diff --git a/src/_pytest/outcomes.py b/src/_pytest/outcomes.py
index b08e7d2c9..0cd1072ef 100644
--- a/src/_pytest/outcomes.py
+++ b/src/_pytest/outcomes.py
@@ -8,7 +8,7 @@

 from packaging.version import Version

-from _pytest.compat import TYPE_CHECKING
+TYPE_CHECKING = False  # avoid circular import through compat

 if TYPE_CHECKING:
     from typing import NoReturn

[blueyed]

Should be good now.
Could be simplified when we decide to not support < 3.5.2 though, but is also trivial to do later of course.

[blueyed]

Rebased on master.
Needs/should be done for src/_pytest/config/argparsing.py then when merging into features.