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

211–220 of 232 posts

Re: Boring Python: Code quality

#211

Post by nomel »

hbrn wrote: post #196
nomel wrote: post #152

Earlier quoted context omitted.

> I honestly can't understand why people are so obsessed about types It's a very powerful sanity check that lets me write correct code faster, avoiding stupid bugs that the unit tests will also, eventually, find. And, to me, reading the code is much much nicer. Types provide additional context to what's going on, at first glance, so I don't have to try to guess what something is, based on its name: results: list[Some…

> I don't have to try to guess what something is, based on its name It's probably just a bad example, but in case it isn't: Sounds like you ended up at the same place. You went from guessing what is some_api.get_results(), based on it's name, to guessing what is SomeAPIResult, also based on it's name. If some_api is your library, then you could have just added type hints to get_results() and let type inference do it'…

> guessing what is SomeAPIResult

I disagree. It’s not a guess, it is precisely what it is, where the variable name is free to betray me. A sane IDE/linter will tell me if my local assumption is incorrect, where a variable called result_SomeAPIResult relies on an assumed, possibly ancient, state of reality.

Re: Boring Python: Code quality

#212

Post by hbrn »

nomel wrote: post #211
hbrn wrote: post #196

Earlier quoted context omitted.

> I don't have to try to guess what something is, based on its name It's probably just a bad example, but in case it isn't: Sounds like you ended up at the same place. You went from guessing what is some_api.get_results(), based on it's name, to guessing what is SomeAPIResult, also based on it's name. If some_api is your library, then you could have just added type hints to get_results() and let type inference do it'…

> guessing what is SomeAPIResult I disagree. It’s not a guess, it is precisely what it is, where the variable name is free to betray me. A sane IDE/linter will tell me if my local assumption is incorrect, where a variable called result_SomeAPIResult relies on an assumed, possibly ancient, state of reality.

You do realize nobody writes code like that, right? Even in static typing land people rely on type inference.

list[SomeAPIResult] in your example is redundant. You can get all the benefits of types without it.

Re: Boring Python: Code quality

#213

Post by eesmith »

bombolo wrote: post #207
eesmith wrote: post #198

Earlier quoted context omitted.

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

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

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

Including the same hypothetical first contributor you mentioned earlier, who you think will find using requirements.txt as being too big a barrier to entry.

Onboarding occurs either way.

I get that you don't like using black - and that's fine! I don't use black on my project either.

But it seems like you're trying to find some other reason to reject black, and constructing hypotheticals that don't make any sense.

Just say you don't like black's choices, and leave it at that.

Re: Boring Python: Code quality

#214

Post by nomel »

hbrn wrote: post #212
nomel wrote: post #211

Earlier quoted context omitted.

> guessing what is SomeAPIResult I disagree. It’s not a guess, it is precisely what it is, where the variable name is free to betray me. A sane IDE/linter will tell me if my local assumption is incorrect, where a variable called result_SomeAPIResult relies on an assumed, possibly ancient, state of reality.

You do realize nobody writes code like that, right? Even in static typing land people rely on type inference. list[SomeAPIResult] in your example is redundant. You can get all the benefits of types without it.

Type inference is good for the writer, not the reader.

Relying on type inference isn’t some rule. Your can find many projects that use it selectively, being explicit where it makes sense. The point of writing code is to make it readable and maintainable. The explicit type isn’t redundant, it’s explicit in presentation, and can be functional, like my example.

I mean, just look at this example. You know the type without having to dig in, do you not? You don’t have to look at the function definition. You know immediately. That’s the point of being explicit, where it makes sense. No guessing, where it makes sense. This is why we have all these type hints now, in a dynamic language: because guessing sucks.

Re: Boring Python: Code quality

#215

Post by IshKebab »

bombolo wrote: post #208
IshKebab wrote: post #184

Earlier quoted context omitted.

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

> I consider the extra effort that automatic formatting causes for code reviews.

Why would it cause extra effort? Not having automatic formatting causes extra effort because you have to tell people to fix their formatting!

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

I'm sure small things change but large differences? No way. Even the differences between YAPF and Black aren't that big in most cases.

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

Right but you have a pre-push hook to format the code using the same version of Black as is used in CI. Then CI won't ever fail.

> I can't cherry pick bug fixes from one branch to the other, because black fails my CI.

Cherry pick, then run Black. Sounds like you have a very awkward workflow to be honest.

Re: Boring Python: Code quality

#216

Post by stinos »

captnswing wrote: post #89
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.

yes it does. see see https://github.com/charliermarsh/ruff#supported-rules for the rules it supports. "IOO1" being the code for isort relevant section from my pyproject.toml [tool.ruff] line-length = 88 # pyflakes, pycodestyle, isort select = ["F", "E", "W", "I001"]

But does it just lint, or also effectively sort the imports?

Re: Boring Python: Code quality

#217

Post by jsmeaton »

bombolo wrote: post #69
jsmeaton wrote: post #59

Earlier quoted context omitted.

This is mostly nonsense and FUD. We have virtualenvironments, requirements files, setup.py with extra_requires that can all be used to manage versions without relying on the particular packages installed on an OS. Most people contributing to open source would be familiar with at least some of these methods and if they are not it’s a good opportunity for learning. And if they are not, then maintainers can pull, run bl…

> Having a tool that dictates formatting is a lot less oppressive to new developers than 100 comments nitpicking style choices. Yes, it would work very well if said tool didn't change its mind every 6 months, generating huge commits at every bump > Most people contributing to open source would be familiar with at least some of these methods and if they are not it’s a good opportunity for learning. You seem unfamiliar…

I’m working in a Python code base with multiple millions of files and not for the first time. It’s not the problem you make it out to be. The changes between black versions have been almost unnoticeable for years.

Re: Boring Python: Code quality

#218

Post by jsmeaton »

aitchnyu wrote: post #114
jsmeaton wrote: post #50

Earlier quoted context omitted.

You can annotate the manager and get some typing help in the editor. And there’s django-stubs which helps a little when running mypy. It’s not as good as pycharm though. https://github.com/typeddjango/django-stubs/tree/master

Could you share a guide on that?

I don't have anything specific but here's something I quickly threw together demonstrating what I mean https://gist.github.com/jarshwah/1e683416d2ed2df28f254fc787d...

Re: Boring Python: Code quality

#219

Post by bombolo »

eesmith wrote: post #213
bombolo wrote: post #207

Earlier quoted context omitted.

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

> 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. A human might add one or two items to a list, decide it's now too long, and make 1 line into 10 lines. Including the same hypothetical first contributor you mentioned earlier, who you think will find using requirements.txt as being too big a barrier to entry. Onboarding occurs either way. I get that…

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

At which point I tell him to split formatting and actual changes into different commits (see https://mtlynch.io/code-review-love/).

> I get that you don't like using black - and that's fine! I don't use black on my project either.

Well according to this comment, it's because we are noobs: "the people that disagree just haven't figured out that they're wrong yet"

> But it seems like you're trying to find some other reason to reject black, and constructing hypotheticals that don't make any sense.

After the n-th time I have to re-setup the entire virtual env on a different branch just to re-run black and isort to backport a fix to a release branch… it does get tiring.

I presume most people here just do websites and don't really have a product that is released to customers who pay to support old versions for years, so black changing syntax is a 1 time event rather than a continuous source of daily pain.

But it seems the commentators here don't have the experience to know there might be a use case they didn't think of.

Re: Boring Python: Code quality

#220

Post by dragonwriter »

ReflectedImage wrote: post #41
anderskaseorg wrote: post #33

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

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…

> You should never be using static typing with a scripting language like Python or Ruby.

You should use it where it makes sense, and not where it doesn’t. I haven’t used any of Ruby’s type checkers, but Python makes this easy enough; make what has a reason to be dynamic dynamic, and have static safety rails everywhere else.

(This is true with many “statically typed” languages that have dynamic escape hatches, too, not just traditionally “scripting” languages.)

Post reply on HN