GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Add a constant that's False at runtime but True when type checking · Issue #230 · python/typing

Add a constant that's False at runtime but True when type checking #230

New issue
Copy link
New issue
Copy link
Closed
Closed
Add a constant that's False at runtime but True when type checking#230
Copy link
Milestone
3.5.2

Description

@gvanrossum
gvanrossum
opened on Jun 4, 2016
Issue body actions

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).

Activity

  1. gvanrossum
    added this to the 3.5.2 milestone on Jun 4, 2016
  2. gvanrossum
    added
    enhancement
    on Jun 4, 2016
  3. gvanrossum commented on Jun 6, 2016

    @gvanrossum
    gvanrossum
    on Jun 6, 2016
    MemberAuthor
    More actions

    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

    if False:
        from typing import ...

    or

    try:
        from typing import ...
    except ImportError:
        ...

    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.

  4. gnprice commented on Jun 6, 2016

    @gnprice
    gnprice
    on Jun 6, 2016
    More actions

    This would be nice to get into the 3.5.2 release if we can.

    Some name ideas:

    typing.in_typechecker
    typing.in_type_system
    not typing.at_runtime
    typing.typechecker is not None  # else 'mypy', 'pytype', 'semmle', etc.
    

    Out of those I think I'd go for in_typechecker (or in_type_checker), but I don't have a strong view.

  5. gnprice commented on Jun 6, 2016

    @gnprice
    gnprice
    on Jun 6, 2016
    More actions

    /cc @markshannon , since this came up in discussion at PyCon last week

  6. JukkaL commented on Jun 7, 2016

    @JukkaL
    JukkaL
    on Jun 7, 2016
    Contributor
    More actions

    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: ...
    
  7. refi64 commented on Jun 7, 2016

    @refi64
    refi64
    on Jun 7, 2016
    More actions

    IMO it really should be some kind of present tense verb to emphasize "if currently type checking".

    Maybe typing.TYPE_CHECKING?

  8. JukkaL commented on Jun 7, 2016

    @JukkaL
    JukkaL
    on Jun 7, 2016
    Contributor
    More actions

    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.

  9. gvanrossum commented on Jun 7, 2016

    @gvanrossum
    gvanrossum
    on Jun 7, 2016 via email
    MemberAuthor
    More actions
    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.
  10. markshannon commented on Jun 7, 2016

    @markshannon
    markshannon
    on Jun 7, 2016
    Member
    More actions

    We could generali(s|z)e TYPE_CHECKING to STATIC_CHECKING, but TYPE_CHECKING is fine (I don't want to bike shed too much).

  11. gvanrossum commented on Jun 7, 2016

    @gvanrossum
    gvanrossum
    on Jun 7, 2016
    MemberAuthor
    More actions

    @matthiaskramm any objection to TYPE_CHECKING?

    --Guido (mobile)
    On Jun 7, 2016 11:24 AM, "Mark Shannon" [email protected] wrote:

    We could generali(s|z)e TYPE_CHECKING to STATIC_CHECKING, but
    TYPE_CHECKING is fine (I don't want to bike shed too much).

    —
    You are receiving this because you authored the thread.
    Reply to this email directly, view it on GitHub
    #230 (comment), or mute
    the thread
    https://github.com/notifications/unsubscribe/ACwrMhol27dTYRoZwmWAO4dekhcy3jg4ks5qJbddgaJpZM4IuLP7
    .

  12. matthiaskramm commented on Jun 7, 2016

    @matthiaskramm
    matthiaskramm
    on Jun 7, 2016
    Contributor
    More actions

    I'm happy with typing.TYPE_CHECKING.

  13. gvanrossum commented on Jun 7, 2016

    @gvanrossum
    gvanrossum
    on Jun 7, 2016 via email
    MemberAuthor
    More actions
    OK, typing.TYPE_CHECKING it is. I'll send the changes soon.
  14. gvanrossum
    added a commit that references this issue on Jun 7, 2016

    Add TYPE_CHECKING constant. Fixes #230.

    This issue will close once commit 2496ab4 is merged into the 'main' branch.
    2496ab4
  15. gvanrossum
    closed this as completedin #234on Jun 8, 2016
  16. gvanrossum
    added a commit that references this issue on Jun 8, 2016

    Add TYPE_CHECKING constant. Fixes #230. (#234)

    This issue will close once commit 600c07f is merged into the 'main' branch.
    600c07f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      • 3.5.2

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.