Pythonista Stubs

Stubs for the Pythonista iOS API. This allows for better error detection and IDE / editor autocomplete.

Installation and Usage

pip install pythonista-stubs --upgrade

N.b. you may need to pip3, particularly if you installed python3 with homebrew

Type checking can then be performed with mypy

• PyCharm: Works immediately
• Vim: vim-mypy
• Emacs: using Flycheck and Flycheck-mypy
• Sublime Text: SublimeLinter-contrib-mypy
• Atom: linter-mypy
• VS Code: provides basic integration with mypy.
• flake8: flake8-mypy

See also: mypy integrations

API Coverage

Built With

• mypy
• Typing Extensions

PEPs

• PEP 484 -- Type Hints
• PEP 561 -- Distributing and Packaging Type Information
• PEP 3107 -- Function Annotations

Contributing

Please file a bug report for any issues you find. Even more excellent than a good bug report is a fix for a bug, or the implementation of a much-needed stub. We'd love to have your contributions.

We use the usual GitHub pull-request flow, which may be familiar to you if you've contributed to other projects on GitHub. For the mechanics, see Mypy's git and GitHub workflow help page, or GitHub's own documentation.

Code Formatting

This project is linted with pyflakes and makes strict use of Black for code formatting.

Conventions

• long functions and methods should be split up with one argument per line
• all function bodies should be empty
• prefer ... over pass
• prefer ... on the same line as the class/function signature
• avoid vertical whitespace between consecutive module-level functions, names, or methods and fields within a single class
• use a single blank line between top-level class definitions
• do not use docstrings
• use variable annotations instead of type comments
• for arguments with a type and a default, use spaces around the =
• use float instead of Union[int, float]
• avoid Union return types: https://github.com/python/mypy/issues/1693
• imports in stubs are considered private unless they use the form from library import name as name
• avoid using the Any type when possible
• type variables and aliases for legibility reasons should be prefixed with an underscore to make it obvious to the reader they are not part of the stubbed API.
• these conventions derived from typeshed

Code of Conduct

Everyone participating in this community is expected to treat other people with respect and more generally to follow the guidelines articulated in the Python Community Code of Conduct.

Authors

• Harold Martin - harold.martin at gmail

Disclaimer

This is not an official project and is not associated with omz:software

License

Apache License 2.0