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

131–140 of 232 posts

Re: Boring Python: Code quality

#131

Post by burntsushi »

bombolo wrote: post #123
burntsushi wrote: post #111

Earlier quoted context omitted.

Bottom line is that the lock file in ripgrep's repo hasn't prevented it from being packaged. And I haven't heard of any distro maintainer complain about any lock file in any Rust program ever. So you're just plain empirically wrong about lock files preventing Rust programs from being packaged. You've now moved on to talking about something else, which is "how much Rust software is packaged." Well, apparently enough t…

> So you're just plain empirically wrong about lock files preventing Rust programs from being packaged. My mistake, seems rust packagers gave up on decent packaging. It isn't so for the python policy, I can assure you :)

I haven't heard anyone complain about how Rust programs are packaged. Take your passive aggressive bullshit somewhere else.

Re: Boring Python: Code quality

#132

Post by toastal »

Not agreeing/disagreeing with the message, but the style of writing here is quite nice. It's focused, reasoned, and doesn't make too many assumptions about your tools and environment--and I appreciate that acknowledgment.

Re: Boring Python: Code quality

#133

Post by burntsushi »

bombolo wrote: post #122
dontlaugh wrote: post #109

Earlier quoted context omitted.

The distros will eventually stop this dangerous practice of mixing and matching versions for all dependencies. It can only work for a small set of system components, which is what every other OS does.

It's more dangerous to let people pin dependencies and have vulnerable libraries in use forever.

Who says the distros are using the lock file? AFAIK, Debian doesn't use ripgrep's lock file, for example. They don't have to, because of semver.

Re: Boring Python: Code quality

#134

Post by hbrn »

bombolo wrote: post #65
ReflectedImage wrote: post #61

Earlier quoted context omitted.

Anyone with experience of writing both dynamic typed and statically typed can tell you that. Infact, you could just try it out for yourself. But here is your internet source for this blatantly obvious fact: https://games.greggman.com/game/dynamic-typing-static-typing...

I do have such experience and I really can't tell that. Which is why I wondered if anyone else was in fact saying that. > But here is your internet source for this blatantly obvious fact: https://games.greggman.com/game/dynamic-typing-static-typing ... Ah no I meant a proper peer reviewed source. The claim that untyped code has fewer bugs is completely bonkers, so I was quite sure that no such source existed. Why do…

> The claim that untyped code has fewer bugs is completely bonkers

Not really. It is, however, quite expensive to measure, because dynamic typing really shines at the evolution of software, that is being able to respond fast to changing requirements. Legos vs play-doh: https://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-pr...

> Why do you think microsoft, google and facebook are all in the business of typechecking

A billion flies can't be wrong? Companies with unlimited amount of money are not the right place to search for good practices. Both Facebook and Google became flush with cash way before modern type obsession. Sure, once you are a multi-billion dollar company slowing down can be a good thing. But you need to get there first.

> If typechecking would actually introduce bugs, it'd be better not doing it right?

If sugar caused us to die sooner, we'd be better to eating too much if it, right? And yet, here we are.

Re: Boring Python: Code quality

#135

Post by hbrn »

ReflectedImage wrote: post #113
bombolo wrote: post #104

Earlier quoted context omitted.

You seem to have no experience with type hints… You could have acquired this experience but didn't. No shame, but you are not the most qualified person to comment on typing. Also python3 is from 2008, and it's effectively a different programming language.

I have experience in working on statically typed Python codebases, it's just obviously inferior. I'll go further and tell you the most common reason for using static typing is to allow the codebase to be a monolith like it's still the 90s. You shouldn't be trying to build a monolith in a scripting language it's a recipe for disaster. I'm a polyglot, I'm exactly the sort of person who should be commenting. Does it sur…

> most common reason for using static typing is to allow the codebase to be a monolith like it's still the 90s

This is so true. Static typing shines when you have a very complicated deeply nested system. And that's what most teams are naturally end up creating.

But how about not building the complicated system in the first place? Most of complexity in modern software is accidental.

Re: Boring Python: Code quality

#136

Post by nine_k »

411111111111111 wrote: post #72
nine_k wrote: post #66

Earlier quoted context omitted.

We have Black as a pre-commit hook; works fine, even if it disagrees with your IDE a little bit sometimes. CI/CD has no business changing your code; it builds stuff using it, exactly as if commit such-and-such.

> CI/CD has no business changing your code; it builds stuff using it, exactly as if commit such-and-such. That going too far unless you define code to be a subset of the files checked into the repository and simply define any file that's touched in an automated manner to be not code There are a lot of useful automations that can be part of the CI/CD pipeline, such as increasing a version number, generating a changelo…

It's not about not trusting automated generation of certain artifacts. Stamping version numbers may be a fair idea. (A changelog entry needs human review and approval, in my book.)

It's mostly about the flow of data and control: source files, beside some known auto-generated files / single lines, are the source, and whatever is generated is downstream from them, not altering them. It's like a React app: data flows through props in only one direction, you don't patch DOM in event handlers, or something.

Re: Boring Python: Code quality

#137

Post by Stratoscope »

dontlaugh wrote: post #108
drcongo wrote: post #92

Earlier quoted context omitted.

Not going to argue about your personal preference, but in Python spaces for indentation isn't just a personal preference - you'll run into a fair amount of issues with that, this one being just the tip of the iceberg.

Not necessarily. Consistently indenting with tabs and aligning with spaces does work, but is tricky to enforce.

The key to success with tabs in any language is simple: Don't use alignment.

Instead, only use indentation.

It is interesting to note that Black-formatted code uses indentation only and never uses alignment. It would be perfectly compatible with tabs, unlike Google-formatted code which relies heavily on column alignment.

Re: Boring Python: Code quality

#138

Post by ReflectedImage »

bombolo wrote: post #112
ReflectedImage wrote: post #106

Earlier quoted context omitted.

I'm sure you could find it on Google Scholar. I'm not your personal googler. My wages disagree with that statement. But hey, we can't all be 10x. Did it ever occur to you to think about why people use scripting languages or what advantages they have over regular programming languages? Of course not, you are used to statically typed languages and are blinded to the idea that there are other ways to develop software. I…

Your "sources" were a blog with opinions based on questionable statistics methods and a stackoverflow with a 404 link. > My wages disagree with that statement. But hey, we can't all be 10x. Just a hint: this screams insecurity. Wealth does not correlate with knowledge. Especially since you don't even use type hints, so you have no professional experience with them. Just an ill formed opinion by reading blogs and comm…

"I did not bother. The fact that microsoft, google and facebook invest money into it is proof enough. You reject it because you're being irrational."

Basically, you are saying you are a cargo cultist rather than a serious software developer.

You fail to understand that the software practices of large multi-national companies are rarely good.

Good luck flying your plane: https://www.abyssapexzine.com/2020/03/cargo-cult/

Re: Boring Python: Code quality

#139

Post by hbrn »

Smotko wrote: post #77
jkukul wrote: post #51

Earlier quoted context omitted.

> 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 100% this. I also let Black auto-format code in the CI and commit these formats. A lot of developers, intentionally or not, don't have commit hooks properly setup. If Black doesn't change the code in CI they need to spend another cycle manually fixing the issues that Blac…

I don't understand why people are against this so much. Black does a sanity check and compares the AST before and after to make sure there aren't any meaningful changes (unless you are running it with --fast). So there is almost no risk that it will break your code. There is nothing more frustrating than coming back from a coffee break only to find out that you have to rerun your CI check because of a trivial formatt…

If you use feature branches, it is quite annoying that can't push two consecutive commits because CI changed something in your branch and now you have to resolve conflicts.

Re: Boring Python: Code quality

#140

Post by hbrn »

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.

> It's easy and rises code quality

Absolutely not. This leads to testing being invasive and driving the design of your software, usually at the cost of something else (like readability). Testing is a tool, you can't let it turn into a goal.

Post reply on HN