Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Boring Python: Code quality

b-list.org

Post reply on HN
Print view View original

11–20 of 232 posts

Re: Boring Python: Code quality

#11

Post by SPBS »

selcuka wrote: post #6
_8j50 wrote: post #4

I don't work on large python projects, mostly just small scripts that need to work well (integrating with a 3rd party rest api is a good example). I don't do CI or unittests but I use git. This is because it takes time and honestly no one outside of myself would care for small stuff like that. But I do run autopep8 and pylint it (I ignore stuff like line being too long,broad exception handling or lack of docs). My co…

> Even now, I dread new python versions because some dependency would start using those features If a dependency breaks compatibility with earlier Python versions because the author wants to use a fancy new feature is not really the fault of Python, is it? Library authors should target the earliest supported Python version they can. Being backwards compatible (at which Python has been doing a good job since the 2->3…

It doesn’t mean it’s Python’s fault, but it fosters a culture where Python developers who regularly follow the language and are some of the ecosystem’s biggest authors are enticed to trying out the fancy new features (even if the old way still works) because “this is cleaner, this is how I want to do things from now on”.

Re: Boring Python: Code quality

#12

Post by anderskaseorg »

If you aren’t happy with Flake8, Pylint, and isort (or maybe if you are!), I recommend checking out Ruff:

https://github.com/charliermarsh/ruff

It’s literally 100 times faster, with comparable coverage to Flake8 plus dozens of plugins, automatic fixes, and very active development.

Re: Boring Python: Code quality

#13

Post by anderskaseorg »

LtWorf wrote: post #10
_bohm wrote: post #5

Earlier quoted context omitted.

For your dependency/versioning issue, use a virtualenv per-project and pin your dependency versions in requirements.txt

Don't pin unless it's needed. I have a library… most downloaded version is 3 years old. The newer versions are massively faster but nobody uses them.

You should not pin the public requirements that get uploaded with a library (listed in setup.py, setup.cfg, or pyproject.toml), since that will restrict your downstream users, leading to version conflicts and persistent security vulnerabilities.

But it’s totally reasonable to pin the private requirements that you develop it against (listed in requirements.txt, poetry.lock, or similar), updating them every so often during the course of development, so that contributors can use a consistent set of tools.

Re: Boring Python: Code quality

#14

Post by eesmith »

bombolo wrote: post #7

> I recommend using two tools together: Black and isort. Black formats things differently depending on the version. So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth. isort's completely random… For example the latest version I tried decided to alphabetically sort all the imports, regardless if they are part of standard library or 3rd party. This is a big change…

> All those big changes introduce commits that make git bisect generally slower.

Bisection search is log2(n) so doubling the number of commits should only add one more bisection step, yes?

> Which might be awful if you also have some C code to recompile at every step of bisecting.

That reminds me, I've got to try out ccache (https://ccache.dev/ ) for my project. My full compile is one minute, but the three files that take longest to compile rarely change.

Re: Boring Python: Code quality

#15

Post by bombolo »

kuu wrote: post #9
bombolo wrote: post #7

> I recommend using two tools together: Black and isort. Black formats things differently depending on the version. So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth. isort's completely random… For example the latest version I tried decided to alphabetically sort all the imports, regardless if they are part of standard library or 3rd party. This is a big change…

> Black formats things differently depending on the version. Then add black as part of your environment with an specific version...

Or wait until a more sensible formatting tool comes along.

Reformatting the whole code every version isn't so good. It's also very slow.

Re: Boring Python: Code quality

#16

Post by bombolo »

eesmith wrote: post #14
bombolo wrote: post #7

> I recommend using two tools together: Black and isort. Black formats things differently depending on the version. So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth. isort's completely random… For example the latest version I tried decided to alphabetically sort all the imports, regardless if they are part of standard library or 3rd party. This is a big change…

> All those big changes introduce commits that make git bisect generally slower. Bisection search is log2(n) so doubling the number of commits should only add one more bisection step, yes? > Which might be awful if you also have some C code to recompile at every step of bisecting. That reminds me, I've got to try out ccache ( https://ccache.dev/ ) for my project. My full compile is one minute, but the three files tha…

> Bisection search is log2(n) so doubling the number of commits should only add one more bisection step, yes?

And testing 1 extra step could only add a 1 hour build more, yes?

Re: Boring Python: Code quality

#17

Post by nxpnsv »

bombolo wrote: post #7

> I recommend using two tools together: Black and isort. Black formats things differently depending on the version. So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth. isort's completely random… For example the latest version I tried decided to alphabetically sort all the imports, regardless if they are part of standard library or 3rd party. This is a big change…

Two developers on the same python project should also use the same version... with poetry it is straightforward to keep track of dev dependencies. Reorder python imports is an alternative for isort: https://github.com/asottile/reorder_python_imports

Re: Boring Python: Code quality

#18

Post by powersnail »

_8j50 wrote: post #4

I don't work on large python projects, mostly just small scripts that need to work well (integrating with a 3rd party rest api is a good example). I don't do CI or unittests but I use git. This is because it takes time and honestly no one outside of myself would care for small stuff like that. But I do run autopep8 and pylint it (I ignore stuff like line being too long,broad exception handling or lack of docs). My co…

To be fair, 2.7->3.0 was big for everyone. Python quite literally became a different language. Since then, nothing has been as dramatic as that.

Re: Boring Python: Code quality

#19

Post by sgtnoodle »

eesmith wrote: post #14
bombolo wrote: post #7

> I recommend using two tools together: Black and isort. Black formats things differently depending on the version. So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth. isort's completely random… For example the latest version I tried decided to alphabetically sort all the imports, regardless if they are part of standard library or 3rd party. This is a big change…

> All those big changes introduce commits that make git bisect generally slower. Bisection search is log2(n) so doubling the number of commits should only add one more bisection step, yes? > Which might be awful if you also have some C code to recompile at every step of bisecting. That reminds me, I've got to try out ccache ( https://ccache.dev/ ) for my project. My full compile is one minute, but the three files tha…

Perhaps the poster meant that the contents of the commits themselves make bisection slower? By touching a lot of files unnecessarily, incremental build systems have to do more work than otherwise.

Re: Boring Python: Code quality

#20

Post by LarsDu88 »

I disagree with this assessment on running a static type checker, although I will admit, every update of python over the past 3 years seems to add more and more typing changes which tends to force global typing updates (looking at you Numpy for python 3.12!)

When python converges on consistent typing across its extended numpy and pandas ecosystem, I believe we will be able to move towards a fully JIT'd language.

Post reply on HN