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

51–60 of 232 posts

Re: Boring Python: Code quality

#51

Post by jkukul »

c120 wrote: post #40

Not sure if I like the recommendation to not let Black change your code and just give out errors. 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. Black shouldn't break anything (and hasn't broken anything for me in the years I used it) but in the unlikely case it does it, there's still pytests/unittests after that that…

> 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 Black could have just fixed for them.

You're saying that there's a risk that Black could break your code when formatting? Well, so could developers and I'd trust a machine to be less error-prone.

Re: Boring Python: Code quality

#52

Post by bombolo »

makapuf wrote: post #42
bombolo wrote: post #21

Earlier quoted context omitted.

Both… and version jumps in formatting tool basically will touch every single file.

Every file that changed because rules changed, which shouldn't be frequent, I don't remember black changed radically since its creation, do you have an example of some widespread syntax change ?

Just take a codebase and run black from different ubuntu releases.

The funny thing is that if you run the versions backwards you will NOT obtain identical files with what you started with.

Re: Boring Python: Code quality

#53

Post by [deleted] »

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.

[deleted]

Re: Boring Python: Code quality

#54

Post by bombolo »

eesmith wrote: post #23
bombolo wrote: post #16

Earlier quoted context omitted.

> Bisection search is log2(n) so doubling the number of commits should only add one more bisection step, yes? And testing 1 extra step could only add a 1 hour build more, yes?

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…

Re: Boring Python: Code quality

#55

Post by eCa »

drcongo wrote: post #47
makapuf wrote: post #39

Earlier quoted context omitted.

If your import statements are indented, they must be in control statements (try/except or conditional imports, I fail to see why you would put those in a loop) thus they will be difficult to reorder if you import another module (with different name or stdlib status) on import error.

I'm not sure what you mean here, but package names can be indented without conditionals or tries, as in... from application.module.modules import ( Model1, Model2, Model3, Model4, Model5, Model6 ) iSort handles this fine if you're using spaces for indentation.

> I have no idea how to 
 on HN
  Two or more leading spaces on each line.[1]


[1] https://news.ycombinator.com/formatdoc

Re: Boring Python: Code quality

#56

Post by bombolo »

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…

> Dynamically typed code is 1/3rd the size of statically typed code,

This is absolutely not true.

> Since the code is 1/3rd of the size it contains 1/3rd of the bugs.

That is made up and contrary to all empirical evidence I've ever collected.

I'd be curious if you have a source, but I doubt it.

Re: Boring Python: Code quality

#57

Post by BerislavLopac »

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.

One useful technique for checking whether the tests are actually meaningful is mutation testing - mutmut is a great Python implementation: https://mutmut.readthedocs.io

Re: Boring Python: Code quality

#58

Post by drcongo »

eCa wrote: post #55
drcongo wrote: post #47

Earlier quoted context omitted.

I'm not sure what you mean here, but package names can be indented without conditionals or tries, as in... from application.module.modules import ( Model1, Model2, Model3, Model4, Model5, Model6 ) iSort handles this fine if you're using spaces for indentation.

> I have no idea how to on HN Two or more leading spaces on each line.[1] [1] https://news.ycombinator.com/formatdoc

Thank you, fixed it up.

Re: Boring Python: Code quality

#59

Post by jsmeaton »

bombolo wrote: post #49
fnord123 wrote: post #26

Earlier quoted context omitted.

Install pre-commit: https://pre-commit.com/ Set black up in the pre-commit with a specific version. When you make a commit it will black the files being committed using the specific version of black. As it's a subset, it's fast. As it's a specific version, it's not going back and forth. I hope this solves your issues.

It doesn't… people use a million different distributions. Forcing everyone to use a single version of black means that people will just not bother with your project. The authors of black just don't understand that it'd be ok to introduce new rules to format new syntax, but it isn't ok to just change how previous things work.

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 black over the diff, and commit.

CI prevents poorly formatted code from entering main.

The actual changes between black versions of late have been minor at best. You’re making a mountain out of a molehill.

Having a tool that dictates formatting is a lot less oppressive to new developers than 100 comments nitpicking style choices.

Re: Boring Python: Code quality

#60

Post by mvanbaak »

bombolo wrote: post #49
fnord123 wrote: post #26

Earlier quoted context omitted.

Install pre-commit: https://pre-commit.com/ Set black up in the pre-commit with a specific version. When you make a commit it will black the files being committed using the specific version of black. As it's a subset, it's fast. As it's a specific version, it's not going back and forth. I hope this solves your issues.

It doesn't… people use a million different distributions. Forcing everyone to use a single version of black means that people will just not bother with your project. The authors of black just don't understand that it'd be ok to introduce new rules to format new syntax, but it isn't ok to just change how previous things work.

since developing in python should be done in a virtual env to start with, I fail to see how this will be any problem. The pre-commit documented version of black will be installed in the venv of the project, problem solved.
Post reply on HN