You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a constant that's False at runtime but True when type checking #230
This would provide a standard idiom for including imports that are only necessary while type checking, see e.g. python/mypy#1646 (which currently recommends if False: import ... because that's the only way to do it).
There's one case where I think the if False: idiom may still be needed: to import the typing module itself. Some code has the constraint that it shouldn't depend on any 3rd party packages. For Python 2.7 and for 3.2--3.4 the only reasonable ways to do that are either
ifFalse:
fromtypingimport ...
or
try:
fromtypingimport ...
exceptImportError:
...
To survive the non-existence of the typing module, some idioms can't be used (especially type aliases, type variables, and generic classes) but many others are still available (especially # type comments for function signatures and variables, and function annotations in string quotes).
We probably should add some language to the PEP to direct type checkers to support at least one of these (which would then become the preferred way). Currently I've mostly been recommending if False: for this, because it's easiest to write.
Here are some more ideas (with an usage example to better illustrate what it would look like):
if typing.type_checker: # could be similar to Greg's typechecker, but with _
from model import Person
if typing.type_check:
from model import Person
if typing.TYPE_CHECK: # this is probably my favorite
from model import Person
if typing.CHECKER:
from model import Person
if typing.STATIC:
from model import Person
if typing.ANALYZE:
from model import Person
if not typing.RUNNING:
from model import Person
if not typing.RUNTIME:
from model import Person
Also, should this be okay if I don't want to use string literals in annotations:
if TYPE_CHECK:
from model import Person
else:
Person = 'Person'
def show(p: Person) -> None: ...
TYPE_CHECKING sounds pretty good to me. This (along with many of the other suggestions) has the minor drawback that it implies a particular sort of tool, even though other tools such as pure type inference tools, refactoring tools or IDEs that don't do type checking can also use these imports.
Maybe ANALYZING? Or would the Brits and Aussies get mad at us?
I do like TYPE_CHECKING, and at least for IDEs that seems a fine usage. It
also feels intuitive so we won't have to explain it to most people who see
it for the first time.
Activity
gvanrossum commentedon Jun 6, 2016
There's one case where I think the
if False:idiom may still be needed: to import the typing module itself. Some code has the constraint that it shouldn't depend on any 3rd party packages. For Python 2.7 and for 3.2--3.4 the only reasonable ways to do that are eitheror
To survive the non-existence of the typing module, some idioms can't be used (especially type aliases, type variables, and generic classes) but many others are still available (especially
# typecomments for function signatures and variables, and function annotations in string quotes).We probably should add some language to the PEP to direct type checkers to support at least one of these (which would then become the preferred way). Currently I've mostly been recommending
if False:for this, because it's easiest to write.gnprice commentedon Jun 6, 2016
This would be nice to get into the 3.5.2 release if we can.
Some name ideas:
Out of those I think I'd go for
in_typechecker(orin_type_checker), but I don't have a strong view.gnprice commentedon Jun 6, 2016
/cc @markshannon , since this came up in discussion at PyCon last week
JukkaL commentedon Jun 7, 2016
Here are some more ideas (with an usage example to better illustrate what it would look like):
Also, should this be okay if I don't want to use string literals in annotations:
refi64 commentedon Jun 7, 2016
IMO it really should be some kind of present tense verb to emphasize "if currently type checking".
Maybe
typing.TYPE_CHECKING?JukkaL commentedon Jun 7, 2016
TYPE_CHECKINGsounds pretty good to me. This (along with many of the other suggestions) has the minor drawback that it implies a particular sort of tool, even though other tools such as pure type inference tools, refactoring tools or IDEs that don't do type checking can also use these imports.gvanrossum commentedon Jun 7, 2016
markshannon commentedon Jun 7, 2016
We could generali(s|z)e
TYPE_CHECKINGtoSTATIC_CHECKING, butTYPE_CHECKINGis fine (I don't want to bike shed too much).gvanrossum commentedon Jun 7, 2016
@matthiaskramm any objection to TYPE_CHECKING?
--Guido (mobile)
On Jun 7, 2016 11:24 AM, "Mark Shannon" notifications@github.com wrote:
matthiaskramm commentedon Jun 7, 2016
I'm happy with
typing.TYPE_CHECKING.gvanrossum commentedon Jun 7, 2016
Add TYPE_CHECKING constant. Fixes #230.
Add TYPE_CHECKING constant. Fixes #230. (#234)