yapf
ale
yapf | ale | |
---|---|---|
21 | 133 | |
13,661 | 13,303 | |
0.3% | 0.5% | |
8.0 | 8.7 | |
8 days ago | 4 days ago | |
Python | Vim Script | |
Apache License 2.0 | BSD 2-clause "Simplified" License |
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.
yapf
-
Enhance Your Project Quality with These Top Python Libraries
YAPF (Yet Another Python Formatter): YAPF takes a different approach in that it’s based off of ‘clang-format’, a popular formatter for C++ code. YAPF reformats Python code so that it conforms to the style guide and looks good.
-
Why is Prettier rock solid?
I think I agree about the testing and labor of complicated translation rules.
But it doesn't appear that almost every pretty printer uses the Wadler pretty printing paper. It seems like MOST of them don't?
e.g. clang-format is one of the biggest and best, and it has a model that includes "unwrapped lines", a "layouter", a line break cost function, exhaustive search with memoization, and Dijikstra's algorithm:
https://llvm.org/devmtg/2013-04/jasper-slides.pdf
The YAPF Python formatter is based on this same algorithm - https://github.com/google/yapf
The Dart formatter used a model of "chunks, rules, and spans"
https://journal.stuffwithstuff.com/2015/09/08/the-hardest-pr...
It almost seems like there are 2 camps -- the functional algorithms for functional/expression-based languages, and other algorithms for more statement-based languages.
Though I guess Prettier/JavaScript falls on the functional side.
I just ran across this survey on lobste.rs and it seems to cover the functional pretty printing languages influenced by Wadler, but functional style, but not the other kind of formatter ("Google" formatters perhaps)
https://arxiv.org/pdf/2310.01530.pdf
-
A Tale of Two Kitchens - Hypermodernizing Your Python Code Base
To get all your code into a consistent format the next step is to run a formatter. I recommend black, the well-known uncompromising code formatter, which is the most popular choice. Alternatives to black are autoflake, prettier and yapf, if you do not agree with blacks constraints.
-
Front page news headline scraping data engineering project
Use yapf to format code -> https://github.com/google/yapf
-
Confused by Google's docstring "Attributes" section.
Google is surprisingly rigorous when it comes to code formatting. I have been a software engineer at Amazon and it was nothing like what the book says happens at Google. So the conventions you see for python docstring formatting are primarily designed to integrate with Google's internal tooling. By using docstrings following the Google conventions, you will ultimately end up with automated documentation and other fancy automated things (like type checking which they did in the docstring before there were type hints). Also notably, Google has an open source python formatting tool that they use internally called YAPF (which stands for "Yet Another Python Formatter". So if you really want to go all-in on Google python style, grab that, too.
- Alternate python spacing.
-
Not sure if this is the worst or most genius indentation I've seen
https://github.com/google/yapf has configs, do ctrl+f SPLIT_COMPLEX_COMPREHENSION in the readme
- Google Python Style Guide
-
Enable hyphenation only for code blocks
Only as recommendation: If the lines of the source code (here: you C code you aim to document) are kept short, in manageable bytes (similar to entries parser.add_argument in Clark's "Tiny Python Projects", example seldomly pass beyond the frequently recommended threshold of 80 characters/line), reporting with listings becomes easier (equally, the reading of the difference logs/views by git and vimdiff), than with lines of say 120 characters per line. Though we no longer are constrained to 80 characters per line by terminals/screens and punch cards (when Fortran still was FORTRAN), this is a reason e.g., yapf for Python allows you to choose between 4 spaces/indentation (PEP8 style), or 2 spaces/indentation (Google style).
-
3 popular Python style guides that will help your team write better code
There is also a formatter for Python files called yapf that your team can use to avoid arguing over formatting conventions. Plus, Google also provides a settings file for Vim, noting that the default settings should be enough if you're using Emacs.
ale
-
A decent VS Code and Ruby on Rails setup
I saw no mention of RBS+Steep, the latter providing a LSP. I use it a lot and very much like it, although it's still young and needs love, but it's making good, steady progress! I've been very pleasantly surprised by some of the crazy things Steep can catch, completely statically!
You appear to be working on projects with Sorbet (which I tried to like but found it fell short in practice, notably outside of the app use case i.e it's mostly useless for gems) so it may be a tall order to try on those. Maybe you can give RBS+Steep a shot on some small project?
RBS: https://github.com/ruby/rbs
RBS collection (for those gems that don't ship RBS signatures in `sig`, integrates with bundler): https://github.com/ruby/gem_rbs_collection
Steep: https://github.com/soutaro/steep
VS Code: https://github.com/soutaro/steep-vscode
Sublime Text: https://github.com/sublimelsp/LSP
Vim (I'm working on it): https://github.com/dense-analysis/ale/pull/4671
-
Laravel code-quality tools
Support for code quality tools are provided by the ALE plugin. These are supported for PHP:
-
Embracing Common Lisp in the Modern World
I mostly agree, though I find Allegro and LispWorks severely lacking in areas too. The companies themselves don't seem to care much about their IDEs. Certainly not in the way JetBrains cares about IntelliJ.
Tucked away in the McCLIM project is Clouseau, which you can quickload and use as a normal user: https://codeberg.org/McCLIM/McCLIM/src/branch/master/Apps/Cl... One small cool thing it does is if you inspect a complex number it will also draw a little x-y vector. (Though trying it out again just now it's overlapping with the text... maybe I should file a bug, but I've only now just learned they moved off github, and I'm not going to make a codeberg account. Friction wins this round.) It does take a while to first compile and load all the dependencies, especially 3bz, another weakness of at least our free Lisps; AFAIK there's still no equivalent of make -j for compiling systems.
I'm a happy vim user (though there is some jank with slimv, admittedly, but it's mostly prevalent around multiple thread situations) and setup the command ,ci to call my own clouseau-inspect function; it just inspects a symbol with clouseau instead of slimv's inspector. Also have a janky watch/unwatch pair of functions that just refreshes the inspector every second. (https://github.com/Jach/dots/blob/master/.sbclrc#L113 if curious, some other junk in .swank.lisp and .vimrc too, and there's https://github.com/dense-analysis/ale/issues/4061 to call sblint on your project...)
But better forms of these sorts of graphical tools are what I hope to one day see more of and are how the free Lisps can close the gap in this area with the commercial Lisps. I believe there's not much Allegro can do that poking around SBCL can't do, but for many things it's just nicer to have a GUI. Want to explore all the symbols and values in a package? Easy enough to script that, but not as nice as just having a table of symbols, and even nicer if you can set watches on some of them. None of the tools need to be tightly integrated with a single IDE either, because all the stuff necessary to debug Lisp is in the running Lisp itself. It's just that the GUI situation continues to suck.
LSP has gotten more popular with other languages and editors, sometimes I wonder if the acronym was made as an inside joke because it's basically how Lisp + Slime/Swank have worked...
-
A Humble Request for Assistance Maintaining ALE
Hello Everyone! w0rp here. I thought I'd ask on Reddit if there's anyone out there would like to help maintain ALE. It would be nice to have another willing volunteer who is up for providing relevant feedback on PRs, answering common questions, merging good PRs, and managing GitHub issues. I'll mention to anyone interested that I have a general policy of never closing issues, no matter how old, unless they are actually either solved or invalid. I bear no compulsions to ensure an that a number of issues, which is arbitrary, remains low. I have a relatively simple vetting process, which mostly just requires building trust over time.
-
Static Analysis Tools for C
A similarly useful list is vim's famous ALE plug-in's list of supported linters:
* https://github.com/dense-analysis/ale/blob/master/supported-...
While less comprehensive¹, this is my go-to list when I start working with a new language. Just brew/yum/apt installing the tool makes it work in the editor²
¹this list mostly has foss,static analyzers, however anyone can contribute (mine was the gawk linting)
²alright,there are some. Tools that might need some setup
-
Tell HN: Vim Has Autocomplete
Ctrl-X Ctrl-L is line based completion, see :help CTRL-X_CTRL-L for details.
:help ins-completion gets the useful docs, Vim's own docs are very good and worth spending some time learning how to use, so you can learn Vim itself better.
Another favorite of mine is 'gf' to open the filename under the cursor, very useful combined with ^X ^F.
Omni completion is also useful: https://vim.fandom.com/wiki/Omni_completion although you're better off with plugin that uses LSP now, for example https://github.com/dense-analysis/ale
-
LazyVim
FWIW, I still use regular vim with ale [0] and it does everything I want. It formats files with Black and isort, shows ruff and pyright errors, supports jumping to definitions, and has variable information available on hover. I have collected my config over the past several years, but I pretty rarely encounter errors with it.
[0]: https://github.com/dense-analysis/ale [1] https://github.com/CGamesPlay/dotfiles/blob/master/files/.co...
-
How to configure vim like an IDE
At some of those syntax things neovim behaves better, and like. But there is https://github.com/dense-analysis/ale.
-
Vim users who work without any plugins, how does your vimrc look like?
I replace ALE with :!, like :! %. If the linter output is compatible with default errorformat , then I do :! % > /tmp/linter.txt then :cgetfile (or in one-go: :cgetexpr systemlist(''))
-
Per project settings for linters used by ALE, how to do it the right way?
I'm not doing much of anything in Python, but according to :help ale-python-pylint:
What are some alternatives?
black - The uncompromising Python code formatter
vim-lsp - async language server protocol plugin for vim and neovim
isort - A Python utility / library to sort imports.
coc.nvim - Nodejs extension host for vim & neovim, load extensions like VSCode and host language servers.
flake8
YouCompleteMe - A code-completion engine for Vim
autopep8 - A tool that automatically formats Python code to conform to the PEP 8 style guide.
nvim-lspconfig - Quickstart configs for Nvim LSP
awesome-python-typing - Collection of awesome Python types, stubs, plugins, and tools to work with them.
syntastic - Syntax checking hacks for vim
pyright - Static Type Checker for Python
nvim-lint - An asynchronous linter plugin for Neovim complementary to the built-in Language Server Protocol support.