pycodestyle
pytype
pycodestyle | pytype | |
---|---|---|
7 | 21 | |
4,983 | 4,538 | |
0.4% | 0.4% | |
7.1 | 9.8 | |
21 days ago | 7 days ago | |
Python | Python | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pycodestyle
-
Enhance Your Project Quality with These Top Python Libraries
PEP8 (pycodestyle): Named after Python’s PEP 8 style guide, this tool checks your Python code against some of the style conventions in PEP 8.
-
flake8-length: Flake8 plugin for a smart line length validation.
pycodestyle linter (used in Flake8 under the hood by default) already has E501 and W505 rules to validate the line length. flake8-length provides an alternative check that is smarter and more forgiving.
-
2 Static Analysis Tools to Enhance Your Productivity
[flake8] max-line-length = 88 ignore = # False positive whitespace before ':' on list slice. # See https://github.com/PyCQA/pycodestyle/issues/373 for details E203
-
Code Quality Tools in Python
Linters analyze code to detect various categories of issues like logistical issue and stylistic issues. Some popular linters are Pylint, pycodestyle, Flake8 and Pylama.
-
A simple randomic "Rock Paper Scissors"
Regarding item 4), sorry to make a relatively minor correction to your very helpful post, but you linked to a four-year-old version of a tool that has received many updates since. Here is the current version (note that the project has been renamed). In addition, it is decidedly not an official tool; making its unofficial status clear was the reason for the name change.
-
[plugin] pycodestyle.nvim
Link. When I write Python I usually have pycodestyle as my linter, and this got me thinking: If I already have a linter configuration for a project, why not just use the linter configuration as my editor configuration as well? The linter configuration is useful to others even if they use a different editor and I don't have to duplicate it in a local vimrc or editorconfig file. I can just use what I already have.
-
How to run program from everywhere (on CLI) like pycodestyle
setuptools provides an easy way to do this via entry_points. Here's the relevant part of setup.py in pycodestyle
pytype
-
Google lays off its Python team
it's open source! check out https://github.com/google/pytype and https://github.com/google/pytype/blob/main/docs/developers/t... for more on the multi-file runner
-
Enhance Your Project Quality with These Top Python Libraries
Pytype checks and infers types for your Python code - without requiring type annotations. Pytype can catch type errors in your Python code before you even run it.
-
A Tale of Two Kitchens - Hypermodernizing Your Python Code Base
Pyre from Meta, pyright from Microsoft and PyType from Google provide additional assistance. They can 'infer' types based on code flow and existing types within the code.
-
Mypy 1.6 Released
we've written a little bit about what pytype does differently here: https://google.github.io/pytype/
our main focus is to be able to work with unannotated and partially-annotated code, and treat it on par with fully annotated code.
-
Mypy 1.5 Released
So, I tried out pytype the other day, and it was a not a good experience. It doesn't support PEP 420 (implicit namespace packages), which means you have to litter __init__.py files everywhere, or it will create filename collisions. See https://github.com/google/pytype/issues/198 for more information. I've since started testing out pyre.
-
Writing Python like it's Rust
What is the smart money doing for type checking in Python? I've used mypy which seems to work well but is incredibly slow (3-4s to update linting after I change code). I've tried pylance type checking in VS Code, which seems to work well + fast but is less clear and comprehensive than mypy. I've also seen projects like pytype [1] and pyre [2] used by Google/Meta, but people say those tools don't really make sense to use unless you're an engineer for those companies.
Am just curious if mypy is really the best option right now?
[1] https://github.com/google/pytype
-
PyMEL's new type stubs
At Luma, we're using mypy to check nearly our entire code-base, including our Maya-related code, thanks to these latest changes. Fully adopting mypy (or an alternative like pytype) is no small feat, but working within a fully type-annotated code base with a type checker to enforce accuracy is like coding in a higher plane of existence: fewer bugs, easier code navigation, faster dev onboarding, easier refactoring, and dramatically increased confidence about every change. I wrote about some deeper insights in these posts.
-
The Python Paradox
Check out https://github.com/google/pytype
-
Forma: An efficient vector-graphics renderer
i work on https://github.com/google/pytype which is largely developed internally and then pushed to github every few days. the github commits are associated with the team's personal github accounts. pytype is not an "official google product" insofar as the open source version is presented as is without official google support, but it is "production code" in the sense that it is very much used extensively within google.
-
Ruff – an fast Python Linter written in Rust
pytype dev here - thanks for the kind words :) whole-program analysis on unannotated or partially-annotated code is our particular focus, but there's surprisingly little dark PLT magic involved; in particular you don't need to be an academic type theory wizard to understand how it works. our developer docs[1] have more info, but at a high level we have an interpreter that virtually executes python bytecode, tracking types where the cpython interpreter would have tracked values.
it's worth exploring some of the other type checkers as well, since they make different tradeoffs - in particular, microsoft's pyright[2] (written in typescript!) can run incrementally within vscode, and tends to add new and experimentally proposed typing PEPs faster than we do.
[1] https://github.com/google/pytype/blob/main/docs/developers/i...
What are some alternatives?
black - The uncompromising Python code formatter
mypy - Optional static typing for Python
Flake8 - flake8 is a python tool that glues together pycodestyle, pyflakes, mccabe, and third-party plugins to check the style and quality of some python code.
pyright - Static Type Checker for Python
autopep8 - A tool that automatically formats Python code to conform to the PEP 8 style guide.
pyre-check - Performant type-checking for python.
flake8-too-many - A flake8 plugin that prevents you from writing "too many" bad codes.
pyannotate - Auto-generate PEP-484 annotations
pyflakes - A simple program which checks Python source files for errors
pyanalyze - A Python type checker
editorconfig-vim - EditorConfig plugin for Vim
ruff - An extremely fast Python linter and code formatter, written in Rust.