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

181–190 of 232 posts

Re: Boring Python: Code quality

#181

Post by timothycrosley »

bombolo wrote: post #173
timothycrosley wrote: post #148

Earlier quoted context omitted.

> 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 of behaviour from what it was doing before. This is not isort! isort has never done that. And it has a formatting guarantee across the major versions that it actively tests against projects online that use it on every sin…

It did this to me today…

Are you using any custom settings?

Re: Boring Python: Code quality

#182

Post by hbrn »

bombolo wrote: post #180
hbrn wrote: post #135

Earlier quoted context omitted.

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

> But how about not building the complicated system in the first place? "For every complex problem, there's a solution that is simple, neat, and wrong."

Read it carefully. Complicated is not the same as complex.

Re: Boring Python: Code quality

#183

Post by dang »

bombolo wrote: post #67
throwawaaarrgh wrote: post #63

Earlier quoted context omitted.

> So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth. Any team of developers who aren't using the exact same environment are going to run into conflicts. At the very least, there must be a CI job that runs quality gates in a single environment in a PR and refuses to merge until the code is correct. The simplest way is to just fail the build if the job results in…

> Any team of developers who aren't using the exact same environment are going to run into conflicts. You've never done any open source development I guess? Do you think all the kernel developers run the same distribution, the same IDE, the same compiler version? LOL. Same applies for most open source projects.

Would you please stop breaking the site guidelines? You've been doing it repeatedly, unfortunately. We want thoughtful, curious conversation here—not flamebait, unsubstantive comments, and swipes.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

Re: Boring Python: Code quality

#184

Post by IshKebab »

bombolo wrote: post #177
IshKebab wrote: post #118

Earlier quoted context omitted.

What's the alternative? YAPF is even worse - it will flip flop between styles even on the same version! Its output is much less attractive, and there are even some files we had to whitelist because it never finishes formatting them (Black worked fine on the same files). Not using a formatter at all is clearly worse than either option.

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

Maybe you meant "why is Black specifically better than no autoformatting, given that it isn't perfectly stable across versions?" in which case the answer is:

a) In practice it is very stable. Minor changes are easily worth the benefits.

b) They have a stability guarantee of one calendar year which seems reasonable: https://black.readthedocs.io/en/stable/the_black_code_style/...

c) You can pin the version!!

Re: Boring Python: Code quality

#185

Post by burntsushi »

bombolo wrote: post #178
burntsushi wrote: post #154

Earlier quoted context omitted.

I didn't say it wasn't a pain point or that there weren't challenges. I said I don't hear about people complain about how Rust programs are packaged. Not that the packaging of Rust programs (among others) itself doesn't present interesting challenges depending on the policies of a particular distro. Archlinux, for example, has far fewer problems than Debian because of differences in policy. The poster I was respondin…

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.

Re: Boring Python: Code quality

#186

Post by ReflectedImage »

TrickardRixx wrote: post #155
ReflectedImage wrote: post #41

Earlier quoted context omitted.

You should never be using static typing with a scripting language like Python or Ruby. Dynamically typed code is 1/3rd the size of statically typed code, that means that one developer who is using dynamic typing is equivalent to 3 developers using statically typed code via MyPy. Since the code is 1/3rd of the size it contains 1/3rd of the bugs. This is confirmed by all the studies that have been done on the topic. If…

Please see Raymond Hettinger's keynote on efficiently handling bugs[0]. He makes the case that static type checking is a boon for Python except for in specific programs that make extensive use of covariant and/or contravariant types. [0] https://www.youtube.com/watch?v=ARKbfWk4Xyw

Increasing the time to market by a factor of 3 is never worth it.

Re: Boring Python: Code quality

#187

Post by ReflectedImage »

bombolo wrote: post #169
ReflectedImage wrote: post #138

Earlier quoted context omitted.

"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-cul…

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

You literally told me that you are a cargo cultist and your words should not to be listened to in your previous comment.

No one who has really tried both would conclude that static typing is better hence I know you are lying. :p

Re: Boring Python: Code quality

#188

Post by dragonwriter »

hbrn wrote: post #176
dragonwriter wrote: post #164

Earlier quoted context omitted.

> See, I feel the exact opposite: I use Iterable only if I have a reason to force consumers to use Iterable. A broad argument type doesn’t force consumers not to use a narrower type. (It forces the implementer of the function to not rely on additional features of the narrower type, but if I am writing the function, I can be certain whether or not that is acceptable.) Meanwhile, using a narrower type than needed for a…

> Since all lists are Iterables but not all Iterables are lists, Iterables are necessarily more ubiquitous than lists. Yeah, that's what I meant by being pedantic :) Here's a question: you receive a JSON payload that contains a list. You will then pass this list to two functions, one of them only iterates, another one uses list interface (let's say checks length among other things). Should you mark the argument as a…

> Solely from the code perspective, it's definitely an Iterable. But in my mental model it still remains a list.

A list is an iterable with special additional features, so this is no conflict at all.

> I don't like it when code deviates from my mental model

But how is there a deviation; being an Iterable is part of being a list, not a deviation from it.

> Forcibly treating it as an Iterable only makes it more complicated, while not giving anything in return.

How is there anything “forcible”. Broader typing doesn’t “forcibly” impose anything. And it does give something, more freedom to callers.

> Sure, you could say that callee should not have expectations of the caller, but what if those functions are already coupled?

If there is coupling that exists for good cause and demands a list as the type of the data structure to be passes around, then, fine, use list. But usually Iterable or Sequence makes more sense; coding to interfaces which impose only what is actually required is better than to unnecessarily specific concrete types.

Re: Boring Python: Code quality

#189

Post by BeefySwain »

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.

That is about as large of an endorsement as I can conceive. Will definitely have to check it out!

Re: Boring Python: Code quality

#190

Post by hbrn »

dragonwriter wrote: post #188
hbrn wrote: post #176

Earlier quoted context omitted.

> Since all lists are Iterables but not all Iterables are lists, Iterables are necessarily more ubiquitous than lists. Yeah, that's what I meant by being pedantic :) Here's a question: you receive a JSON payload that contains a list. You will then pass this list to two functions, one of them only iterates, another one uses list interface (let's say checks length among other things). Should you mark the argument as a…

> Solely from the code perspective, it's definitely an Iterable. But in my mental model it still remains a list. A list is an iterable with special additional features, so this is no conflict at all. > I don't like it when code deviates from my mental model But how is there a deviation; being an Iterable is part of being a list, not a deviation from it. > Forcibly treating it as an Iterable only makes it more complic…

> But how is there a deviation; being an Iterable is part of being a list, not a deviation from it.

Because I'm a human, not a robot. If I can describe something with fewer words by sacrificing a little bit of accuracy, I might go for it when I don't deem that accuracy to be important.

If wife sends you to buy eggs, are you the type of person that buys caviar because "technically they're eggs"?

> coding to interfaces which impose only what is actually required is better than to unnecessarily specific concrete types

Of course. Although practicality beats purity.

Post reply on HN