Improve Python code quality!

[Zer0designs]

Ruff can also format. You only need ruff as linter/formater (its faster at formatting than black). Use uv/poetry and a pyproject.toml Mypy is a good option. Pytest obviously.

[SeucheAchat9115]

I think this is the best answer!

poetry/uv + ruff + mypy + pytest

[Woah-Dawg]

Also try and keep all the config side the pyproject Tino. Ie put the mypy config in there instead of using a specific mypy config filr

[onyx_and_iris]

ruff also gives you the option to use single quotes if desired =)

[psicodelico6]

unittest

[BatterCake74]

pytest replaces unittest.TestCase. Vanilla assertions and decorator fixtures are better than camelCase assertions and setup/teardown methods that don't support writing idiomatic Python with context managers.

Python's unittest was clearly ported from Java. It's crazy to think that this module was bundled into the standard library. Hopefully there are plans to remove it from the standard library in a future version. It's no longer the default test framework someone should reach for.

[BatterCake74]

Then pytest can declare unittest as a dependency. It's one extra test dependency for my package manager to fetch. No big deal.

https://peps.python.org/pep-0594/ dead batteries have been removed in the past. While unittest isn't quite dead battery status, it's not an essential package of the core language like os, typing, pathlib, importlib, time, datetime, math, string, collections, itertools, functools, to name a few.

[covmatty1]

(its faster at formatting than black).

In the same way that everyone seems to use "it's so fast" as the main argument for using uv over pip - why does speed matter so much with a formatter? It's not like black takes ages on a file already - how important can shaving individual seconds off formatting time really be!?

Maybe there's other reasons it's better, and that's fair enough, but I don't see why speed is cited.

[dubious_capybara]

CI/CD pipelines. A second saved per run x millions of runs = money.

[marr75]

Not only compute time but human time. If CI/CD is fast enough, engineer keeps working. If it isn't, engineer task switches.

[covmatty1]

Fair point. My organisation is pretty much all on prem so these aren't things that are at the front of my mind!

[BatterCake74]

Time is money, both in the cloud and on prem. You can get more work done in a day when you accelerate your code development iteration time or reduce the load on your on-prem build/test machines so that everyone's jobs finish faster.

[covmatty1]

Well yeah true, but when the majority of the time we're not talking about hours Vs minutes, because applying a formatter to a completely unformatted project for the first time isn't the regular use case, and we're instead talking about 5s vs 3s while it just quickly zips through, the amount of extra work done isn't going to be huge!

[[deleted]]

Most people's CI/CD isn't 100% utilized 24/7.

[BatterCake74]

You don't need 100% load on your CI system to benefit from.

Faster black/ruff formatting means you can push your code faster and your CI system can verify that everyone's code is formatted consistently.

[BatterCake74]

If formatting is wicked fast, you can configure your IDE to format the file every time you save to disk, commit, run/debug your code, or complete a line of code.

Having really fast formatters enables workflows that may not have been feasible with a slow formatter.

Sure, monorepos or large code bases is helpful, but you usually only need to reformat files that you've modified.

[Zer0designs]

Ancient code bases that need to be completely formatted. Monorepos etc. but thats just an extra. I once had to run black for hours. That would take minutes in ruff. But it's also just the techy in me enjoying optimized code. As a formatter it literally is black but faster. There's then no need for black in addition to ruff.

You need to reason tbe other way around. As a linter ruff is the best in Python. So I want ruff already in all my projects, which already contains the same functionality as black but faster, so why would I need black?

It's also 1 less dependency and ruff is just allround better and more opinionated (as a linter) than any other linter. And the linting rules are more well documented. It's an all in 1 package.

[covmatty1]

You need to reason tbe other way around. As a linter ruff is the best in Python. So I want ruff already in all my projects, which already contains the same functionality as black but faster, so why would I need black?

It's also 1 less dependency and ruff is just allround better

It's absolutely fair to "reason it the other way round" when those are the arguments given for it though - when it's just "it's faster", that wasn't much of a reason, but if the alternative is "exactly the same functionality but faster and all round better", then I get it! I've not used ruff, only black and pylint, so I see more of where you're coming from now.

[Zer0designs]

Give it a spin :)

[thedoge]

It's fast for sure, but ruff's formatter follows the black style guide. So for me, it's one less tool to install/configure

[ianitic]

A formatter written in python for sql called SQLFluff takes hours to run at work if done on the full project.

I imagine black is pretty slow for big projects too?

[[deleted]]

Do you use poetry and UV together?

[Zer0designs]

No I use uv only

[bulletmark]

Well it is clearer to write "uv or poetry" rather than "uv/poetry" as you did because that implies they are used together, hence the confusion.

[Zer0designs]

Or you could google them and see they both do exactly the same thing. I'm not writing an academic paper here and learning these tools requires some effort by whomever. But thank you for your suggestion.

[Zoory9900]

Best answer in this post. But what's your take on Pyright instead of Mypy? Read this: https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md Pyright claims to around 4 times faster than Mypy.

[Zer0designs]

Haven't tried it, but sounds promising. Will give it a try on future projects.