pyre-check VS isort

Internally we use Pyre for Python type checking: https://github.com/facebook/pyre-check

Before type hinting, work had intense rules and linters enforcing docstrings with types. Now, type hints and automatic pyre runs take care of all the heavy lifting.

Python now has an optional type system and if you add one of them such as mypy or pyre to your CI process and you can configure GitHub to refuse the pull request until types are added you can make it somewhat strongly typed.

If you have a preexisting codebase I believe the way you can convert it is to add the types that you know on commits and eventually you will have enough types that adding the missing ones should be easy. For the missing ones Any is a good choice.

https://pyre-check.org and https://github.com/python/mypy are popular.

So to find things in a similar space, you need to look for languages with these sorts of constraints - so things like Sorbet for Ruby or pyright/pyre and you'll see similar and new ideas

Facebook/Instagram uses Pyre which is a typechecker for Python.

I'd be curious if the pyre-check compilation is any faster for you either by removing the inlining optimization flag (the `-Oclassic` here https://github.com/facebook/pyre-check/blame/36243764ab81a82...) or whether there's a way to compile pyre-check to bytecode instead of the native compilation step (which unfortunately it looks like there's no easy way to modify pyre-check's build config to do so).

I must be doing something wrong.

[1] https://github.com/facebook/pyre-check

Some other good alternatives for type checking are Pyright (which is seen in VSCode via Microsofts PyLance plugin) and Pyre.

repos: ... pre-commmit stuff ... black stuff - repo: https://github.com/pycqa/isort rev: 5.12.0 hooks: - id: isort name: isort (python)

isort

isort , A Python utility / library to sort imports.

Install black and isort and just don't worry about it. :-)

Sure. Also, and don't take this the wrong way, but there are some code smells in your project that could be partially mitigated with some basic linting/formatting. I suggest black as a code formatter, flake8 for basic linting, and isort for sorting imports (for example, you have local imports mixed in with standard library and third party imports). You can install these via pip and most editors (like VS Code) can autoformat on save and show you linting problems as you edit. And you can integrate these into your workflow by using pre-commit.

The baseline is to start using the tools that are industry standard in Python. Like Black for formatting, flake8 for picking up the common problems, isort for sorting your imports.

Formatting: isort & black

And this rule has been followed the majority(if not all) interpreted and scripting languages. The likes of Ruby, python and JS have multiple examples. Whatever executable is in your $PATH it won’t have an extension.

Not sure if this convention is actually documented anywhere.

Random examples:

- https://github.com/PyCQA/isort/blob/main/pyproject.toml#L100

- https://github.com/pypa/pip/blob/main/setup.py#L78

- https://github.com/11ty/eleventy/blob/master/package.json#L1...

But then... the run failed again and it had to do something with isort. Through this trial and error of multiple runs fails, I learned that there was something called pre-commit that checks a whole lot of things such as formatting and linting and most of my fails were formatting related. I then ran the pre-commit and fixed all errors before pushing my changes. Had I read their contribution guidelines a bit more carefully in the beginning, this would have been a lot easier.

isort – A Python utility / library to sort imports