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

31–40 of 232 posts

Re: Boring Python: Code quality

#31

Post by bombolo »

LarsDu88 wrote: post #20

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.

> I believe we will be able to move towards a fully JIT'd language.

Unless they actually go ahead with the deferred evaluation of types (PEP 563), make all types strings at runtime and make it impossible to know which type they actually are. :)

But they will probably not: https://discuss.python.org/t/type-annotations-pep-649-and-pe...

But it could be a breaking change in the language. As it is, I can run this "a: str = 3" and it will work.

Re: Boring Python: Code quality

#32

Post by liendolucas »

I don't understand. The title of the post is: "Boring Python: code quality". Further down: "Today I want to talk about what's generally called "code quality" - tools to help...". I'm sorry but "code quality" is not "tooling". The post should be titled: "Python tooling". Code quality: What abstractions are you using in your code?, How easy is to make a change?, How easy is to understand your code base?, What patterns are you using and why?, Are you abusing class inheritance?, How many side effects are present out there and how does that affect your program?, Are you taking advantage of the Python language facilities and idioms?, Is it easy to write unit tests for?, etc. To sum up: "tooling" != "code quality".

Re: Boring Python: Code quality

#33

Post by anderskaseorg »

> For example, you basically never care whether something is exactly of type list, you care about things like whether you can iterate over it or index into it.

This is an odd complaint. typing.Sequence[T] has been there since the first iteration of typing (3.5), for exactly that use case, along with many related collection types.

https://docs.python.org/3/library/typing.html

mypy isn’t perfect, but it’s sure better than making things up without any checks; you’re going to want it for all but the smallest projects.

Re: Boring Python: Code quality

#34

Post by drcongo »

gjulianm wrote: post #22
anderskaseorg wrote: post #12

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.

Does ruff replace isort? Because I'm really unhappy with it, it doesn't work with tabs and conflicts with yapf all the time.

> it doesn't work with tabs

What do you mean by this? Are you indenting Python with tabs?

Re: Boring Python: Code quality

#35

Post by simonw »

liendolucas wrote: post #32

I don't understand. The title of the post is: "Boring Python: code quality". Further down: "Today I want to talk about what's generally called "code quality" - tools to help...". I'm sorry but "code quality" is not "tooling". The post should be titled: "Python tooling". Code quality: What abstractions are you using in your code?, How easy is to make a change?, How easy is to understand your code base?, What patterns…

"Boring Python" is the title of the series of posts, which started here: https://www.b-list.org/weblog/2022/may/13/boring-python-depe...

> This is the first in hopefully a series of posts I intend to write about how to build/manage/deploy/etc. Python applications in as boring a way as possible.

It's a riff on Boring Technology, see https://boringtechnology.club/

Re: Boring Python: Code quality

#36

Post by tasuki »

bvrmn wrote: post #29

> Coverage measurements are too easy to “game” — you can get to 100% coverage without meaningfully testing all or even most of your code Still it's a good low bar for testing. It's easy and rises code quality. I have very good results with coverage driving colleagues to write tests. And on code review we can discuss how to make tests more useful and robust and how to decrease number of mocks, etc.

Hard disagree: 100% coverage is not a "good low bar" and does not increase code quality.

Depending on the language and the particular project, my sweet spot for test coverage is between 30-70%, testing the tricky bits.

I've seen 100% code coverage with tests for all the getters and setters. These tests were not only 100% useless, they actively hindered any changes to the system.

Re: Boring Python: Code quality

#37

Post by liendolucas »

simonw wrote: post #35
liendolucas wrote: post #32

I don't understand. The title of the post is: "Boring Python: code quality". Further down: "Today I want to talk about what's generally called "code quality" - tools to help...". I'm sorry but "code quality" is not "tooling". The post should be titled: "Python tooling". Code quality: What abstractions are you using in your code?, How easy is to make a change?, How easy is to understand your code base?, What patterns…

"Boring Python" is the title of the series of posts, which started here: https://www.b-list.org/weblog/2022/may/13/boring-python-depe... > This is the first in hopefully a series of posts I intend to write about how to build/manage/deploy/etc. Python applications in as boring a way as possible. It's a riff on Boring Technology, see https://boringtechnology.club/

It doesn't really matter if it is fun, sad, entertaining or boring Python. The post wrongly claims that putting all these tools in a project will lead to "code quality". It says that at the very beginning as I quoted it. This is harmful, especially for a junior developer or someone that doesn't have much or none experience coding. It will make the naive reader believe that having those tools in place quality code is being produced.

Re: Boring Python: Code quality

#38

Post by Cthulhu_ »

liendolucas wrote: post #37
simonw wrote: post #35

Earlier quoted context omitted.

"Boring Python" is the title of the series of posts, which started here: https://www.b-list.org/weblog/2022/may/13/boring-python-depe... > This is the first in hopefully a series of posts I intend to write about how to build/manage/deploy/etc. Python applications in as boring a way as possible. It's a riff on Boring Technology, see https://boringtechnology.club/

It doesn't really matter if it is fun, sad, entertaining or boring Python. The post wrongly claims that putting all these tools in a project will lead to "code quality". It says that at the very beginning as I quoted it. This is harmful, especially for a junior developer or someone that doesn't have much or none experience coding. It will make the naive reader believe that having those tools in place quality code is…

While it doesn't produce quality, it can help a developer write better code; I've learned tons about JS internals just by sticking to whatever eslint popped up with. Before that I learned tons about Java's internals and best practices by fixing issues that these automated "best practice" tools came up with.

It's far from perfect, but it helps if you don't know any better. And most people don't know any better.

I'm currently spinning up a new project (React Native, Typescript) and I'm spending a lot of effort in locking down the project - eslint, unit tests & coverage, CI, strict typescript rules, etc - because this did not happen with the previous iteration of this project, leading to tens of thousands of LOC worth of unit- and end-to-end integration tests to become worthless and unusable. Sure, that was a lack of developer discipline as well, but why rely on other people when you can do it through technology as well? You can't control everyone.

Re: Boring Python: Code quality

#39

Post by makapuf »

drcongo wrote: post #34
gjulianm wrote: post #22

Earlier quoted context omitted.

Does ruff replace isort? Because I'm really unhappy with it, it doesn't work with tabs and conflicts with yapf all the time.

> it doesn't work with tabs What do you mean by this? Are you indenting Python with tabs?

If your import statements are indented, they must be in control statements (try/except or conditional imports, I fail to see why you would put those in a loop) thus they will be difficult to reorder if you import another module (with different name or stdlib status) on import error.

Re: Boring Python: Code quality

#40

Post by c120 »

Not sure if I like the recommendation to not let Black change your code and just give out errors.

I absolutely let Black change code and see the value in Black that it does that so the devs do not have to spend time on manually formatting code.

Black shouldn't break anything (and hasn't broken anything for me in the years I used it) but in the unlikely case it does it, there's still pytests/unittests after that that should catch problems...

Post reply on HN