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

141–150 of 232 posts

Re: Boring Python: Code quality

#141

Post by hbrn »

Lutger wrote: post #75
tasuki wrote: post #36

Earlier quoted context omitted.

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.

This is true. You can have bad unittests which make the system worse and you would be better of without them. You can also have useless unittests with 100% coverage, which is pretty much the same as bad tests because more code means more bugs and more work. Unittests are also code after all. The only thing you can say about a very low coverage is that you probably don't have good tests. That's not a very useful metri…

> Code coverage starts to be useful once you let go of it as a goal and ignore the total percentage number

When a measure becomes a target, it ceases to be a good measure.

It takes immense discipline to actually let go of a metric to keep it valuable.

Re: Boring Python: Code quality

#142

Post by sseagull »

burntsushi wrote: post #131
bombolo wrote: post #123

Earlier quoted context omitted.

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

How Linux package managers handle these newer languages with their own package managers (including rust) is an ongoing pain point. Here’s an article from 2017 about it, and I don’t know if things have improved:

https://lwn.net/Articles/712318/

Re: Boring Python: Code quality

#143

Post by geysersam »

bombolo wrote: post #54
eesmith wrote: post #23

Earlier quoted context omitted.

It could, certainly. But 1) you don't have one black commit for every non-black commit, do you? Because the general best practice is to do like kuu suggested and have a specific black version as part of the development environment, with a pre-commit hook to ensure no random formatting gets introduced. 2) assuming 500 commits in your bisection, that's, what, about 9 compilations you'll need to do, so it will take you…

As I said in other comments, if you try to force contributors to reproduce exactly your local setup, you will be left with no contributors. Which is why you set up a CI to run the tests… because people will most likely not. As for build times, it was an extreme example. But even an extra step taking 5 extra minutes is very annoying to me…

> if you try to force contributors to reproduce exactly your local setup

  python -m venv venv
  pip install -r requirements.txt
Do you consider that imposing? I assumed that was standard. Don't basically all Python projects in existence use something like it?

Re: Boring Python: Code quality

#144

Post by hbrn »

jerrygenser wrote: post #84

Even since the start of python typing, it was recommended to use a more generic type like Iterable instead of List. The author claims that List is too specific -- this seems like a straw man argument against typing that doesn't acknowledge python's own advice. Also, mypy has gotten really good in recent years and I can vouch that on projects that have typing I catch bugs much much sooner. Previously I would only catc…

Iterable is an import away, while list is already at my fingers.

There's zero harm in using list in private interfaces: I know I'm the only one passing the value, I know it is always a list.

As an argument type, Iterable is compatible with list, so it's benefits are minimal (with rare exceptions).

Lists are easier to inspect in a debugging session.

Iterable can be useful as return type, because it limits the interface.

Iterable is useful if you are actually making use of generators because of memory implications, but in this case you already know to use it, because your interfaces are incompatible with lists.

I can count on fingers of my hands when using Iterable instead of list actually made a difference.

Re: Boring Python: Code quality

#145

Post by tandav »

Flex247A wrote: post #91
modeopfer wrote: post #74

What's the current state of the art of managing multiple virtual environments, running tests and running your application? On Ubuntu and Windows I use Poetry [0], and it works, although it has (had?) some quirks during the installation on Windows. I liked its portability and lockfile format though. A few years ago I used conda [1], which was nice because it came batteries included especially for Deep Learning stuff.…

If you feel that Anaconda is too heavy, try Miniconda [0]. The base environment is a standard Python 3.9 environment without any additional packages. [0] https://docs.conda.io/en/latest/miniconda.html

also try mamba which is much faster than conda https://mamba.readthedocs.io/en/latest/index.html

Re: Boring Python: Code quality

#146

Post by craftkiller »

hbrn wrote: post #139
Smotko wrote: post #77

Earlier quoted context omitted.

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.

We have it set up to only run after you've opened a PR. You shouldn't run into the issue often that way because if you're opening a PR then all your big immediate changes are already committed so you won't be pushing another commit until someone reviews which will be after black has already finished.

Re: Boring Python: Code quality

#147

Post by hbrn »

whalesalad wrote: post #126
jerrygenser wrote: post #84

Even since the start of python typing, it was recommended to use a more generic type like Iterable instead of List. The author claims that List is too specific -- this seems like a straw man argument against typing that doesn't acknowledge python's own advice. Also, mypy has gotten really good in recent years and I can vouch that on projects that have typing I catch bugs much much sooner. Previously I would only catc…

> Even since the start of python typing, it was recommended to use a more generic type like Iterable instead of List. The author claims that List is too specific These statements contradict themselves? List is too specific, and Sequence[item] is preferred. Sometimes you are dealing with a tuple, or a generator, and so it makes more sense to annotate that it is a generic iterable versus a concrete list.

Whether something is generic/specific depends on the context.

As an argument type, Iterable is permissive (generic).

As a return type, Iterable is restrictive (specific).

Re: Boring Python: Code quality

#148

Post by timothycrosley »

bombolo wrote: post #7

> I recommend using two tools together: Black and isort. Black formats things differently depending on the version. So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth. 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…

> 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 single commit to the repository: https://pycqa.github.io/isort/docs/major_releases/release_po...

Re: Boring Python: Code quality

#149

Post by hbrn »

craftkiller wrote: post #146
hbrn wrote: post #139

Earlier quoted context omitted.

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.

We have it set up to only run after you've opened a PR. You shouldn't run into the issue often that way because if you're opening a PR then all your big immediate changes are already committed so you won't be pushing another commit until someone reviews which will be after black has already finished.

This really depends on the workflow.

Sometimes I still sneak in minor changes after I opened a PR. Sometimes I open PR early because CI has integration/e2e tests that are hard to run locally. Sometimes I want feedback on certain parts early on and PR is the easiest way to show something.

There can be workflows in which pushing through CI works fine, but as a general advice it's not great because there are many edge cases.

Re: Boring Python: Code quality

#150

Post by liendolucas »

jerrygenser wrote: post #84

Even since the start of python typing, it was recommended to use a more generic type like Iterable instead of List. The author claims that List is too specific -- this seems like a straw man argument against typing that doesn't acknowledge python's own advice. Also, mypy has gotten really good in recent years and I can vouch that on projects that have typing I catch bugs much much sooner. Previously I would only catc…

> The other thing typing does is allow for refactoring code.

No. What allows you confident refactoring code are automated tests. I honestly can't understand why people are so obsessed about types, especially in languages like Python or Javascript.

Post reply on HN