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

201–210 of 232 posts

Re: Boring Python: Code quality

#201

Post by bombolo »

hbrn wrote: post #197
bombolo wrote: post #169

Earlier quoted context omitted.

> Basically, you are saying you are a cargo cultist rather than a serious software developer. No. I'm saying I tried both ways and I know advantages and disadvantages and I'm capable of deciding by myself. You on the other hand did not try both but feign expertise. > Good luck flying your plane: https://www.abyssapexzine.com/2020/03/cargo-cult/ Yes everybody knows what a cargo cult is. It's not some sort of intellect…

No offense, but it's like a textbook on awful debates. Your best arguments are: "big guys are doing it therefore it's good for me too" (argument from authority) and "I tried both and decided only one is good" (argument from authority/anecdotal evidence). Plus a ton of ad hominems. To be fair, your opponent isn't very different.

Awful debate indeed.

I asked for sources and got a 404 link as a response.

I'm told that I earn less money, hence I'm not as good (despite the other person having no idea of how much i earn).

> To be fair, your opponent isn't very different.

And yet, you felt the need to respond to me…

Re: Boring Python: Code quality

#202

Post by bombolo »

burntsushi wrote: post #185
bombolo wrote: post #178

Earlier quoted context omitted.

I contribute to packaging. But thanks for teaching me about something I know already. Now try to get something using an obsolete version of some python module into Fedora or Debian and let me know how it goes… It would not be accepted as it is. It'd be patched to work with a current one or just rejected.

I never said a single word about Python. Whether you contribute to packaging or not has nothing to do with whether you're posting false information. If anything, it makes what you've said worse. You should know better. Just stop spreading misinformation. And the courteous thing to do is to acknowledge an error when it's pointed out instead of doubling down and redirecting as if no error was made.

The article is about python, the thread is about pinning dependencies in python.

Re: Boring Python: Code quality

#203

Post by bombolo »

throwawaaarrgh wrote: post #194
bombolo wrote: post #98

Earlier quoted context omitted.

Using lock files is a good way to make sure your software never ends up in a distribution and in the hands of users.

Distros can keep their own lock file that is based on their own release branch's versions. If it doesn't build, the pkg maintainer will either file a bug report or make a patch, or neither. Source: I maintain distro packages.

But something building doesn't mean that it will work.

There can be changes that are different than function signature changes.

Where dependency pinning is the norm, there is a culture of breaking API compatibility. And you might not have a compiler error to inform you that the API has changed. Sometimes all you have is a commit message.

Re: Boring Python: Code quality

#204

Post by muxator »

timothycrosley wrote: post #160
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.

FWIW, I wrote isort, but am seriously considering migrating my projects to use Ruff. Long term I think the design is just better over the variety of tools we use within the Python ecosystem today. The fact we have a plethora of projects that are meant to run per a commit with each one reparsing the AST independently, and often using a different approach to do so, just feels untenable long term to me.

BTW, thank you for isort!

Re: Boring Python: Code quality

#205

Post by burntsushi »

bombolo wrote: post #202
burntsushi wrote: post #185

Earlier quoted context omitted.

I never said a single word about Python. Whether you contribute to packaging or not has nothing to do with whether you're posting false information. If anything, it makes what you've said worse. You should know better. Just stop spreading misinformation. And the courteous thing to do is to acknowledge an error when it's pointed out instead of doubling down and redirecting as if no error was made.

The article is about python, the thread is about pinning dependencies in python.

> Using lock files is a good way to make sure your software never ends up in a distribution and in the hands of users.

> And how much rust software is packaged in distributions? Almost none.

> They haven't figured out the procedures

You're clearly talking about Rust in the second two comments. Your original comment was just a general pronouncement about lock files. You could perhaps be given the benefit of the doubt that you were only thinking about Python, but someone else interpreted your comment broadly to apply to any language with lock files. If you really only meant it to be specific Python, one would reasonably expect you to say, "Oh, sorry, I was only talking about Python. Not Rust. Their situation might be different."

But no. You doubled down and started spouting nonsense. And you continue to do so!

> Where dependency pinning is the norm, there is a culture of breaking API compatibility.

Rust does not have this problem. It is the norm to use lock files for Rust programs, but there is no culture of "breaking API compatibility" without appropriate signaling via semver.

This entire exchange is a classic example of Brandolini's law: https://en.wikipedia.org/wiki/Brandolini%27s_law

It's easy for you to go off and spout bullshit. You've even been corrected by someone else who maintains distro packages. But it's a lot harder to correct it. You wriggle and squirm and rationalize and deflect.

Re: Boring Python: Code quality

#207

Post by bombolo »

eesmith wrote: post #198
bombolo wrote: post #175

Earlier quoted context omitted.

> How do black reformatting changes cause an extra 5 minutes? Did you even read my comments? Black reformatting causes more steps in bisecting. It's quite easy that a test suite takes 5+ minutes.

None of your comments mention running the full test suite, only build. When I've used bisection, I've always had a targeted test that I was trying to fail, not the entire test suite. This is because the test suite at the time of that commit wasn't good enough to detect this failure. Otherwise it would have failed with that commit. Instead, a new failure mode is detected, an automated test developed, and that used to…

> This is a bad practice. You should be using black as a pre-commit hook

I would reject such commits in review.

A human might add one or two items to a list and black might decide it's now too long, and make 1 line into 10 lines.

Now I have to manually compare the list item by item to figure out what has changed.

So I normally require formatting to be done in a separate commit, because I don't want to review the larger than necessary diffs that come out doing it within the same commit.

Re: Boring Python: Code quality

#208

Post by bombolo »

IshKebab wrote: post #184
bombolo wrote: post #177

Earlier quoted context omitted.

> Not using a formatter at all is clearly worse than either option. why? Do you hate terse diffs in git?

Because some people are really bad at formatting code manually and constantly nitpicking them about it is both tedious and antagonistic. Its much better for a faceless tool to just remove formatting from the equation entirely. I think the sane part of the software engineering world has realised that auto-formatting is just the right way to do it, and the people that disagree just haven't figured out that they're wron…

> the people that disagree just haven't figured out that they're wrong yet.

This is unnecessarily confrontational. Please read my other comments where I consider the extra effort that automatic formatting causes for code reviews.

> In practice it is very stable.

It has never happened to me to upgrade black and have it not change opinion about black formatted code.

> Minor changes are easily worth the benefits.

It doesn't matter how minor they are. A 1 bit difference is still going to fail my CI.

> You can pin the version!!

I usually do, but working with old releases that must be maintained, mean that I can't cherry pick bug fixes from one branch to the other, because black fails my CI.

Re: Boring Python: Code quality

#209

Post by nxpnsv »

bombolo wrote: post #172
nxpnsv wrote: post #17

Earlier quoted context omitted.

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

> Two developers on the same python project should also use the same version Why? It is expected for the thing to run on different python versions and different setups… what's the point of forcing developers to a uniformity that will not exist? It's actually better to NOT have this uniformity, so issues can get fixed before the end users complain about them.

Tooling matters, pretending that it doesn't isn't really going to help you. But you do you...

Re: Boring Python: Code quality

#210

Post by bvrmn »

tasuki wrote: post #36
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.

> 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.

It's a red flag to blame high coverage for fragile tests. Use narrow public component interfaces to reach code parts and you simultaneously gain robust tests which can be used during refactoring and you can be guided by coverage to generate test cases. Bob Martin has a great article: https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContrav...

Post reply on HN