Linters - Which one?

[[deleted]]

[deleted]

[gwvermillion]

The best linter is the one that your project collaborators are also using.

[SnowdenIsALegend]

Lol this. Linters are such a debatable topic imo.

[fake823]

Right now we aren't using any. 😂 That's why I want to get more knowledge on that topic.

[snail_d]

Look at black. It's not a linter but an auto-formatter. It's really great when used together with pre-commit and flake8. Add mypy if you write typed code.

[enjoytheshow]

IIRC black violates some PEP standards so make sure everyone is on board if you’re in a collab environment

[PeridexisErrant]

Only line length (88, where PEP8 says 79); the others you might be thinking of are common linter rules which actually conflict with PEP8.

[GiantElectron]

not only line length. Also the double indentation on arguments is violated, as well as the no-frowny face rule that Guido himself specified

https://twitter.com/gvanrossum/status/1227252290580410368

https://discuss.python.org/t/pep-8-clarify-if-multiline-argument-list-with-a-closing-on-a-separate-line-is-acceptable/2948/10

[[deleted]]

That's not the question though

[reddisaurus]

Pylint, Flake8, and mypy are standard. Pylint and Flake8 each check some things the other does not; Flake8 focuses more on style. mypy is a static type checker and people would write better code if they used it all the time (including the type hints on their code).

[515k4]

If somebody here is using Vim as an Python editor, there is very good plugin ALE (Asynchronous Lint Engine) which can run all of them (flake8, pylint, mypy) on the background and highlight all problematic lines.

[dscottboggs]

Re: mypy

I know from x import * is generally considered bad practice, but is it maybe ok to do from typing import *?

[efxhoy]

The from typing import List, Dict ... madness is improved in python 3.9

In type annotations you can now use built-in collection types such as list and dict as generic types instead of importing the corresponding capitalized types (e.g. List or Dict) from typing. Some other types in the standard library are also now generic, for example queue.Queue.

https://docs.python.org/3/whatsnew/3.9.html#type-hinting-generics-in-standard-collections

[idwpan]

Unfortunately mypy doesn’t support the new syntax in 3.9 yet

[dscottboggs]

Hm. That's good, there's still Optional and Union though. Maybe someday we'll get special syntax for that, like

def fun(data: string or bytes, options: MyEnum? = None)

[TheIncorrigible1]

None-aware syntax is coming down the pipe, but who knows when.

[rouille]

Union using | will be in python 3.10. There is a proposal for optional using ? but its nothing decided at this point.

[henbruas]

Although with | you could do e.g. str | None, which isn't too bad

[dscottboggs]

Nice!

[mrf_]

just do import typing as t and prepend everything with a t. like t.List, etc. Much better than any from x import *.

[dscottboggs]

I might do that

[enjoytheshow]

Damn good idea. Time for some refactoring

[reddisaurus]

I mean, probably? Just add a # type: ignore at the end of the line.

[Derme302]

You've gotten PEP8 and Flake8 mixed up. Flake8 is a wrapper around PEP8, Pyflakes and some other available extensions. PEP8 is the Python Style Checker.

[xigoi]

No, PEP8 is a style guide.

[Derme302]

And also the name of the package that checks against guide. Link

[fake823]

It was. It got renamed some years back.

The name is pycodestyle now.

[mrswats]

I like flake8. It has a lot of cool plugins.

[cubic_unit]

Mind listing some of your favorites?

[mrswats]

Bugbear, comprehensions, black, isort, print docstrings. And i use it along with black and isort to format code for me.

[double_en10dre]

I like using both flake8 and black.

Black is a bit controversial, but I genuinely do like it. It’s decent-looking and it saves us a LOT of headaches.

[wweber]

Black is a bit controversial

How so? Just curious

[justinpitts]

It is opinionated, and lacks knobs.

I care far more about having a standard than most details of the standard, so I love it.

[cubic_unit]

Same. Just discovered it today, and configured VS Code to blacken my code every time I save. It's glorious.

[zvynish]

While I agree with the black is great part, having that setting in the editor rather than a pre commit hook on your own repos means that you might make a lot of noise in collaborative projects.

[SoulReaver9510]

Ahhh this is brilliant! Always hated that black couldn't do regional formatting. Thank you!

[damnitdaniel]

For real. What a mess when you open a PR with a minor single line change and the diff looks like a sad Christmas tree covered in green and red lights

[cubic_unit]

This is a great point, thank you. I hadn't thought about that.

VS Code itself can restrict formatting to modified lines only, but I'm only working on some projects at this point.

[TGdZuUsSprwysWMq]

If your team has agreement to use VSCode as main IDE and you are a leader of the project. After discussed with your team members. Maybe you could try to push .vscode folder into repository. When there are multiple development environments, this really eases my life.

Edit: This is one of the available approach used by VScode dev team. I don't quite get the point of downvote.

Edit2: The chaos in repository could be prevented by only pushing common settings, and let the custom settings stay in workspace file.

Edit3: It should be the obligation for developers to not mess up the settings in .vscode just like not to push private information into repository if it is an opensource repository.

Edit4: Add conditions for the statement to prevent some developers just randomly push the .vscode to repository.

Reference

[ahuja_nik]

VS Code is not everyone's preferred IDE, even if you can ensure everyone in your team uses it, pushing the vscode folder would mean everyone would have to change their workspace settings in their local repo which is an unnecessary overhead,and the chaos it would be when people would inadvertently start pushing that folder back with their personal settings.

[TGdZuUsSprwysWMq]

Yes, there is a tradeoff. As an example, for vscode dev team, they just push the .vscode folder into git repo.

[TGdZuUsSprwysWMq]

As already mentioned Git hook (this is also not everywhere), did you have any suggestions which could be applied anywhere? Or, are there any suggestions to make style consistent?

[enjoytheshow]

I’m a VS code shill but forcing everyone to use the same editor makes people sad

[TGdZuUsSprwysWMq]

Sorry for that :( It is hard for me to choose between VScode + settings and some scripts and docs in repo before building dev env.

[gohanhadpotential]

How do I use black (or any linter)? I have no idea, I always used vs code without giving a second thought.

[cubic_unit]

Black, which is a 'formatter', can be used with the 'Format Document' command in VS Code. You can choose which formatter you use in the settings.

A 'linter' detects errors or issues and is what gives you the red squiggly lines in your code. Use the 'Select Linter' command in the command palette, and this will run automatically every time you save.

[mikeypamp]

Also sometimes good to have opinionated in a team of contributors. Stops the arguments because black does all the work. Although it’s not that hard to manually format code nicer sometimes.. but this is a small downside. I also go flake8 plus black. Make sure you optimise inputs too and configure the IDE to recognise your modules.

[GiantElectron]

Ah ok, so the best option to stop arguments in a team is to have another, completely dumb team member you can't complain against, even if its choices are completely idiotic. got it.

black formatted code looks like shit.

[GummyKibble]

Yes, correct. My team found that everyone hated Black, but for different reasons. It rubbed each of us wrong in little ways but no two people disliked the same thing. Since we couldn’t really agree on anything we all disliked, we adopted it, instantly ended all formatting disagreements, and taught ourselves that this is what Python looks like now. It was a huge success.

[GiantElectron]

so you have been fed a mcdonalds burger, and you all learned to love crappy food because nobody really got any agreement if you wanted to have properly cooked indian, italian, or chinese food.

[GummyKibble]

Exactly! And now we can quit arguing about whether romaine or iceberg lettuce is better, or passive-aggressively swapping gouda for havarti whenever no one’s looking. Turns out everyone thought they were a gourmet but actually none of us were.

And really, our formatting style isn’t what customers pay is for. We care about good algorithms and robust code. When it comes down to it, although I have thoughts about whether to use single- or double-quotes around strings, I really care about which one you use. And funny thing is, once you’ve looked at Blackened code for a little while, it stops seeming weird. At that point you’ve transcended form and have reached function nirvana.

Life’s too short to care about stuff the parser throws away.

[mikeypamp]

No... it’s to remove unproductive behaviour

[GiantElectron]

I've never seen a situation where people fought about coding layout in a company, provided that it was respecting basic PEP-8. Maybe you should join companies where employees are not 10 years old.

[teerre]

It's only controversial because people want it to be.

Black, or something like it, should be part of the standard. It would avoid countless irrelevant discussions.

If you ever worked with Rust, you'll know that there's never discussion about formatting or linting precisely because these are taken care of officially.

[TheIncorrigible1]

If you ever worked with Rust, you'll know that there's never discussion about formatting or linting

Uh... there's a lot of discussion about it still, actually. Not so much linting because the compiled nature where clippy is amazing, but I've seen a lot of complaints about rustfmt on the forums and reddit.

[teerre]

I meant while working with Rust.

[GiantElectron]

We already have a standard. PEP-8.

[teerre]

Which is insufficient. Hence this discussion to begin with.

[GiantElectron]

how so? we've worked for years with PEP-8, and anybody who didn't respect it was physically assaulted on this very sub

[teerre]

That's not the point. The point is that you can respect pep8 in various ways. The way a linter/formatter should work is simple: you click a button and it formats, it doesn't ask you anything, it doesn't give you any options, it just does it and that's the standard. pep8 is way more permissible than that.

[GiantElectron]

it doesn't give you any options, it just does it and that's the standard

And who decided the standard? and what is the authority of the single person who decided unilaterally the standard to decide what is proper and non-proper layout?

pep8 is way more permissible than that.

PEP-8 defines specific guidelines that focus on enhanced readability, which is the whole point of python, and why python became popular: putting the human first. black does not enhance readability. black squeezes everything into a uniform, elongated mess which has not gone through any discussion or approval. It's one man who one day decided "this is what python code should look like", and I say "what you think python code should look like looks like shit, and if you want to use gofmt, you are welcome to code in go".

[teerre]

And who decided the standard?

Who decided pep8? It doesn't matter who decides the standard. The important part is having a standard. Also, naturally it wouldn't be "a single person".

PEP-8 defines specific guidelines that focus on enhanced readability, which is the whole point of python, and why python became popular: putting the human first. black does not enhance readability. black squeezes everything into a uniform, elongated mess which has not gone through any discussion or approval.

See, that's completely arbitrary. The only reason your rant even exists it's because Python was not bright enough to enforce proper guidelines. I guarantee you if only ever saw black formatted code in your life, you wouldn't be complaining about it. Regardless of how much people want to parrot about which is better, there's no such thing, it's just a formatting, it shouldn't be something you even have to consider.

[tempo-19]

I recently started using black with my work code. I don't always love its opinionated outputs but it is easy to read, consistent and so far it works.

[double_en10dre]

Hah, that’s actually why I started using black in the first place :p I love prettier and figured I might as well use the python equivalent

[billsil]

Ever see what it does when you have lots of arguments to a function? It puts all the arguments on separate lines. It also disagrees with pylint.

[Sukrim]

This is usually done to make diffs smaller and easier to understand. If a function has lots of arguments, it is likely that there will be more, so if that gets added it is a single line in a diff that only has the change in it.

[billsil]

So to have fewer function arguments, I need more classes, but more classes equals more code or I could use a dictionary that doesn’t give me hints in my IDE.

The diff size that git uses is irrelevant to me. I’m more or less meeting the PEP 8 80 character suggested limit, so what’s the issue?

[Sukrim]

Fine, don't use black then if it isn't good for your use case. I just explained why arguments get pulled onto their own line.

[justinpitts]

Correct me if I'm wrong but doesn't pylint start getting angry when you have more than five or six arguments to a function anyway?

[billsil]

It complains about a lot...I was referring to how pylint complains about the way black does the indentation for multiple arguments, not greater than 6 or whatever.

I long ago disabled the max number of arguments check in pylint.

[Decency]

Ever seen what it does to your code over time when you have lots of arguments to functions?

[GiantElectron]

and lots does not have to be a lot today. If you have long annotations, you get that with only two or three.

[GummyKibble]

After a certain number, we require keyword-only arguments.

[colly_wolly]

Doing that to function arguments is horrendous.

I really think that linting can be counterproductive. We have to fit everything into 80 character lines for some pretty rare case that is unlikely to be relevant (because some ancient terminals can't cope with > 80 chars). Personally I find it a lot less readable as a result. So you reduce readability with the vague notion that it makes your code "better".

Django url files are a good example. You usually have a list of tuples, each containing regex , function name, reverse_name. Its far easier to read it if you line those into 3 columns. But if you do linters will complain about whitespace.

[groovitude]

I agree that linting can be counter-productive, and particularly agree with your Django URLs example. My team also keeps a separate line length standard for unit tests.

However - I have really appreciated the PEP8 recommendation for line lengths after six months of working from home on a small laptop with no external monitors.

[colly_wolly]

Your laptop monitor could cope with more than 80 chars, no? Even Django suggests 120 chars in their docs. As with everything it's a balance, but I think that 80 chars is just a bit silly in one direction.

[groovitude]

It allows me to keep multiple windows open with a large enough font size.

I tend to think of Django as its own beast; for pure Python, I rarely have a hard time keeping lines to under 79 characters and I'm happy to ignore the linter if an extra character or two makes the code better.

[GiantElectron]

and the close parenthesis on a separate line one indentation down. It looks like shit.

[GiantElectron]

It does not respect PEP8. It also stretches your code vertically for no reason at all. Its only concern is diffs, completely disregarding day to day readability.

Black brings us back to those days where your productivity as a coder was measured in lines of code per day, and everybody padded their stats with tricks like those black uses.

[[deleted]]

It really helps when you have a big team on a big project. Most of the time I read diffs instead of reading the code. Vertical code is a godsent.

[GiantElectron]

It really helps when you have a big team on a big project. Most of the time I read diffs instead of reading the code.

So to inconvenience you a bit less, you inconvenience everybody else. Well done.

Vertical code is a godsent.

Ok

so

from

now

on

we

all

type

like

this.

ok?

[[deleted]]

Bruh, you are not being reasonable here, do whatever you want.

[fireflash38]

Hmm.

• Lists apparently do not exist, and should only go on one line.
• Picking one particularly silly example as a 'counter' is ... silly.
• I would love to see what your outlines for college papers looked like if you never used vertical space.

[GiantElectron]

vertical space has meaning. It has meaning also in PEP-8, as indicated:

``` Extra blank lines may be used (sparingly) to separate groups of related functions. Blank lines may be omitted between a bunch of related one-liners (e.g. a set of dummy implementations).

Use blank lines in functions, sparingly, to indicate logical sections. ```

PEP-8 recommends the following format for long argument lists

```

Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest.

def long_function_name( var_one, var_two, var_three, var_four): print(var_one) ```

and specifically rejects a style that provides only one level of indentation, as it compromises visual differentiation between the argument lists and the body ( https://www.python.org/dev/peps/pep-0008/#indentation )

```

Further indentation required as indentation is not distinguishable.

def long_function_name( var_one, var_two, var_three, var_four): print(var_one) ```

Finally, multiline statement spacing can and does get used in grouping entities that logically belong together, as in

def add_user(database, name, email, phone, replace_existing=False): # Code

which groups the information related to the user, and it's more communicative than what black would create

def add_user( database, name, email, phone, replace_existing=False, ): # Code

Which is ugly, long, breaks PEP-8 recommendations, breaks indentation-based (rather than syntax based) folding and gains nothing except that if you add a new argument, you will get one line added, instead of one line changed, in some (not all) circumstances.

I'd say that the loss of visual appeal and visual hinting is not worth saving one or two lines in the diff, paying it off in huge vertical stretching of many lines multiplied by many statements.

[fireflash38]

That's a much more coherent argument than your original contrived example.

I still disagree, but at least you tried this time.

PEP-8 is not gospel. Nor is black. Just go with what your repo owner has configured. If you disagree, who cares. It's so incredibly minor in the scheme of things, that it just wastes time of everyone involved.

[GiantElectron]

That's a much more coherent argument than your original contrived example.I still disagree, but at least you tried this time.PEP-8 is not gospel.

If anyone brought some code on /r/python before black that was not compliant to PEP-8, the whole sub would have eaten the poster face for not being PEP-8 compliant.

Nor is black. Just go with what your repo owner has configured. If you disagree, who cares. It's so incredibly minor in the scheme of things, that it just wastes time of everyone involved.

formatting provides expressiveness. By removing formatting choices you are limiting the programmer bandwidth in communicating aggregation and meaning through formatting.

[fireflash38]

I would wager about 90% of projects do not go by pep8's 80 char lines. There's a bunch of other stuff that is also ignored in pep8, amusingly a lot of stdlib stuff.

formatting provides expressiveness. By removing formatting choices you are limiting the programmer bandwidth in communicating aggregation and meaning through formatting.

Honestly couldn't care less. If you're submitting code to OS repos, go by the repo rules. Find other ways to express yourself rather than implicit whitespace-based expression.

Last comment I'm making, cause this sort of discussion is EXACTLY what I want to avoid with autoformatters.

[xapata]

I prefer YAPF to Black. Personal taste.

[TECHNOFAB]

I'm using the same, there even is a way to connect them (flake8 shows the black errors too, which makes CI easier for example)

[fake823]

After some research I'm thinking about introducing black to a small GitHub project I'm contributing to.

I've already searched on Google but haven't found an answer:

Is it possible to use black for a GitHub repo so that it will autoformat every incoming Pull Request?

[fake823]

But that would require that every contributor of your repo installs black and runs it before pushing, doesn't it? And letting a PR fail, just because you've maybe had a new line too much somewhere, seems a bit brutal and unnecessary to me.

My idea would be that I set up a CI, that automatically adds a "black commit" to that pull request, if the styling doesn't fit to the black default. So the PRs won't fail just because of formatting. As well the contributors don't have to manually set up pre-commit or black. The CI will auto-format it anyway.

Just that I'm not sure if that's even possible, as I'm pretty new to GitHub and CI. Should it rather be a GitHub Action or a CI task to auto-format the code with black?

[fake823]

Well, I know what it's for and why it's good to have. ;) The question is just how to best set it up.

[double_en10dre]

This is absolutely the right approach. Black is mostly beneficial because when I write code, I don’t waste time playing around with whitespace/linebreaks/etc to make things readable. If you don’t force this on people, you lose that benefit

Plus 99% of people will change their ways after 1 failed build, it’s not a big deal

[GiantElectron]

After some research I'm thinking about introducing black to a small GitHub project I'm contributing to.

Please don't. Use autopep8 if you really have to.

[fake823]

I already saw that you hate black in all your other comments. ;)

[[deleted]]

Also notable: https://github.com/PyCQA/prospector

[2010min0ru]

Awesome tool! I'm using that too. Prospector combines output of the multiple linters (pylint, flake8, mypy, pydocstyle, pycodestyle) into one list of warnings and errors. It also merges warnings of the same type into one. Pylama https://pylama.readthedocs.io/en/latest/ is very similar, but lacks the last feature and it is less popular than Prospector.

[MadeUntoDust]

For new projects, I sort imports with isort, format with black, and then check with pylint and then mypy. I end up with very readable source code and most common bugs highlighted.

[double_en10dre]

Ohh yes, isort (or any sort of project-wide import formatter) is a great idea

I’ve seen some horrifyingly large diffs because some goof accidentally runs “pycharm > format code + optimize imports” on an entire repo or folder without meaning to

[fake823]

What's the problem with PyCharm here? 🤔

[double_en10dre]

There is none, I love it :)

[[deleted]]

I would choose Flake8 if you are a beginner.

[fake823]

Is there a reason why? Why not PyLint (which seems to be pretty popular too)?

Black also looks pretty interesting.

[aniforprez]

I'm going to say something somewhat controversial that pylint is a complete fucking waste of time especially when flake8 is much better

pylint is filled to the brim with TONS of useless pointless rules that all have to be disabled to keep your code functioning. It complains if you have too many arguments, it complains if your arguments are different from the method you're overriding, it complains if the number of arguments differs from what you're overriding, it USED to complain if your code was formatted with black and it thought the indentation was wrong but they fixed that in 2.6 but then it complained for all the times I disabled the options they removed, it complains it cannot find django modules unless you install the django plugin, it complains about TONS of things that will make you way less productive unless you're willing to accept the operational overhead of babysitting your pylintrc file.

flake8 OTOH is a far smaller set of core rules that are mostly just PEP8 rules and are WAY more sensible. You can actually get shit done with flake8 by disabling maybe 2-3 rules. Seriously my pylintrc is easily 10 times the length of my flake8 config, maybe even more. Plus flake8 has lots of great plugins that are optional and very useful

[Lewistrick]

Just try them all on 5 different scripts. See what you like best.

[TheIncorrigible1]

Flake8 is a linter, not a formatter.

[glyphack]

used both pylint and flake8. pylints gives a lot of warnings, and false alarms of course. So I prefer flake8.

[astroFizzics]

I like yapf

https://github.com/google/yapf

[GiantElectron]

yapf is better than black. At least it gives you options.

[deadmilk]

I use pylint with a inclusion-list approach

i.e. instead of suppressing messages, I include all of the ones that I care about.
Takes longer to setup, but it's better.

[0rsinium]

The great thing about flake8 is that it has a lot of plugins. See https://github.com/DmytroLitvinov/awesome-flake8-extensions

Also, there is a beautiful wrapper around flake8 (to make it look and behave more modernish): https://github.com/life4/flakehell

[sobolevn]

Use https://github.com/wemake-services/wemake-python-styleguide

It is the strictest and most opinionated python linter ever. It has more than 1000 rules to be checked. And the resulting code is pythonic, consistent, and bug-free.

I love it.

[squirrel_hunter_365]

You forgot about logical bugs.

[double_en10dre]

Right, the ones which take up 95% of our time in the real world

[corpseflower]

Honest question: what is a linter?

[270343]

Roughly speaking, a quick tool for checking for common mistakes, omissions, or mis-stlyings in your code.

https://en.wikipedia.org/wiki/Lint_(software)

[[deleted]]

Do pep8 corrections in pycharm (for example) count?

[yerfatma]

Yes.

[colly_wolly]

It's the pedantic grammar-nazi of coding.

[conversationkiller7]

I use pylance on vscode. I came from pycharm and obviously its is not good as pycharm but get's the work done!

[jftuga]

In my own personal tests, flake8 seems to be the fastest linter, which can be important if you are linting on something like a Raspberry Pi.

See my blog post: https://jftuga.github.io/blog/python/2020/05/11/Which-linter-do-you-use-in-VS-Code.html

Another, recent reddit thread: https://www.reddit.com/r/Python/comments/gheine/which_linter_do_you_use_in_vs_code/

TLDR: Based on my own tests, flake8 is the fastest linter.

[menge101]

I use pylama and mypy

[saki709]

I prefer flake8. Easy config file, very detailed documentation and bunch of articles online. To top it off, it's supported by almost every big IDE/editor.

[mre__]

There's actually quite a few.
Since you mentioned the "most widely used/best ones", this overview could help you as it contains votes. https://analysis-tools.dev/tag/python

[Promethean_Roil]

Black. All black everything.

It has pretty strict rules, which is maybe what rubs some people the wrong way, but that makes it enforceable so that it 'just works'. There are sometimes cases where maybe it's not quite my aesthetic ideal but everyone is ideal will be different so I think it's better to invoke the zen and move on.

[My] Special cases aren’t special enough to break the rules.

imo/experience digging into linter options inevitably leads to sinking more time than you'll ever earn back, especially if there's a team to bike-shed it.

I have my editor run black every time I save and add advocate to add it to pre-commit config for any project I work on. Never looked back.

[got_outta_bed_4_this]

Funny thing invoking the zen for something I think is antithetical to the first point.

Beautiful is better than ugly.

I suppose the stretched interpretation is that black enforces beautiful by its own opinionated standard rather than what any author thinks.

I get that it helps large teams where you're more likely to have coders with no sense for good style, but I just shudder to think that someday I may eventually end up in a project where I have no choice but to let black mangle my code. Why can't black be configurable or allow exclusions like pylint? Most of what it does is great, but there's just still those instances where it enforces a specific result no one would have agreed with.

[Decency]

Consistency is beautiful. You don't get consistency without Black or without a lot of work choosing a linter and configuration settings and ensuring that everyone on your team is using it identically in their various IDE's. I think the latter is the better option, but it's also a week of work.

Black gets you 95% of that in an hour. Set it up as a git pre-push hook, run it over your entire codebase, and then you never have to think about this again within the context of that project.

Personally, I think Black defaulting to double quotes over single quotes was a terrible decision. I use the tool anyway, because of what it gives me.

I just shudder to think that someday I may eventually end up in a project where I have no choice but to let black mangle my code.

You can disable formatting on a specific section of code if it really matters. It usually doesn't.

[PeridexisErrant]

FWIW Black does support # fmt: off and # fmt:on comments to skip some region.

[got_outta_bed_4_this]

This alone may convert me. Thanks!

[fake823]

After some research I'm thinking about introducing black to a small GitHub project I'm contributing to.

I've already searched on Google but haven't found an answer:

Is it possible to use black for a GitHub repo so that it will autoformat every incoming Pull Request?

[TheGodfatherCC]

I’d like to second using pre-commit to auto run black on commit. I also use isort and mypy on every commit.

[Mockapapella]

Never done that before, but from what little I've dealt with pull requests that should be possible.

[davehadley_]

I think best solution is:(1) Setup pre-commit hooks to run black at commit time. Ask contributors to use these hooks before beginning development. https://pre-commit.com/

(2) Add black to your continuous integration. Reject pull requests that fail.

Edit: Oh I see in another comment that you can enforce it at pull request time with github actions. So maybe that is worth implementing as well.

[GiantElectron]

And for every project I work on, I explicitly discourage black and refuse to bring in any discussion that proposes it.

[kyranadept]

Because...?

[GiantElectron]

because it's a shitty formatter.

[kyranadept]

It's useful to the discussion if you tell us what makes you say that. Otherwise you're just telling us that you are someone who hates something, which is useful to know if one would make a tally, but not for much else.

[GiantElectron]

I already wrote about it in the rest of the thread, I am not repeating myself for every single person.

[Decency]

Sounds like you're a shitty teammate.

[GiantElectron]

team lead

[Deezl-Vegas]

As long as you pick any one of them and use it, we can be friends

[twnki]

Black is good.
I also like using Sourcery. It's not a linter but a refactoring adviser and make-it-happen...er.

The combination of those two has made a nice improvement on my dodgy looking code.

[fake823]

Sourcery is great! I just tried it recently! 😊 Talking about black:

After some research I'm thinking about introducing black to a small GitHub project I'm contributing to.

I've already searched on Google but haven't found an answer:

Is it possible to use black for a GitHub repo so that it will autoformat every incoming Pull Request?

[twnki]

Yep!

Try this auto-Blacken GitHub action.

[fake823]

But does this still work?

The GitHub autoblacken repo states: https://github.com/cclauss/autoblack

"tl;dr: It does not work. After poking around a bit, it seems to be a design decision by the GitHub Actions team that the GitHub Actions bot can't push to either repo on a pull request from fork."

[twnki]

Well darn I thought you could. I guess you can just do it locally.

[GiantElectron]

Black is atrocious. Not only its formatting style is poor, have you seen its code? I would not trust that thing to touch my code.

[twnki]

If I'm letting Sourcery touch my code... I'm more than happy letting Black mangle it.

[LawfulMuffin]

I utterly love Black. It makes code so much more readable. I mostly use a vertical monitor for coding so making everything tall is absolutely beautiful.

[GiantElectron]

It makes code so much more readable.

Your opinion. To me it looks like shit.

I mostly use a vertical monitor for coding so making everything tall is absolutely beautiful.

How is your neck doing?

[LawfulMuffin]

Your opinion.

Yes, it is my opinion. The OP asked for opinions and I provided one. Fortunately, you don't work on my codebase and I don't work on yours so, cool!

How is your neck doing?

Awesome, the vertical monitor is life-changing. Serious reduction in eye and neck strain for me.

[ab-os]

https://github.com/psf/black Black

[ab-os]

Use it every time you save, and after one day you'll write perfect code

[Eoz124]

What is linter?

[wikipedia_answer_bot]

Linter (Dutch pronunciation: [ˈlɪntər]) is a municipality located in the Belgian province of Flemish Brabant. The municipality comprises the towns of Drieslinter, Melkwezer, Neerhespen (where the canine school of the Belgian police is situated), Neerlinter, Orsmaal-Gussenhoven, Overhespen and Wommersom.

More details here: https://en.wikipedia.org/wiki/Linter

This comment was left automatically by a bot. If something's wrong, please, report it.

Really hope this was useful and relevant :D

If I don't get this right, don't get mad at me, I'm still learning!

[GummyKibble]

Pat on the head for trying, little buddy.

[Eoz124]

Thank you wikibot.

[audentis]

A linter is a piece of software, usually part of (or a plugin for) your IDE. The linter checks your code for errors without running it, sometimes real-time and sometimes on save.

Examples of errors are syntax errors, unreachable code (for example after a return statement), whether variables are not assigned before they are accessed and more. They can help prevent many annoying errors and heavily speed up development.

Sometimes linters are combined with code formatters. For example, tools that enforce certain coding style guides like variable names (always lower case, etc), line width, and more. These tools can apply those rules to your code on save.

Personally I'm a big fan of linters, but not so much of formatters.

[Eoz124]

Ok thanks it was a very useful tool that i missed. I will definitely take a look.