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

41–50 of 232 posts

Re: Boring Python: Code quality

#41

Post by ReflectedImage »

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 use a static type checking with Python, you have increased your development time by 3 and your bug count by 3.

Static typing's advantage is that the code runs a lot faster but that's only true if the language itself is statically typed. So with Python you have just screwed up.

Re: Boring Python: Code quality

#42

Post by makapuf »

bombolo wrote: post #21
sgtnoodle wrote: post #19

Earlier quoted context omitted.

Perhaps the poster meant that the contents of the commits themselves make bisection slower? By touching a lot of files unnecessarily, incremental build systems have to do more work than otherwise.

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 ?

Re: Boring Python: Code quality

#43

Post by bsdz »

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…

IIRC, Black also checks byte code before and after formatting to ensure source code functionality is unaffected.

Re: Boring Python: Code quality

#44

Post by dustrider »

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…

As I understood it, it was to not let black do the formatting during CI builds. In local dev you’d let it reformat.

Even while it won’t break anything you want CI to be your safety net, flagging a local setup as being wrong is more valuable than magically autocorrecting it.

Re: Boring Python: Code quality

#45

Post by drcongo »

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.

Just installed this along with ruff-lsp and I'm in love already, thank you!

Re: Boring Python: Code quality

#46

Post by aitchnyu »

I wish VSCode would figure out that ExampleModel.objects.first() returns ExampleModel or None or ExampleModel.objects.filter() returns an iterable of ExampleModel. Has anybody gotten this working, automatically or manually annotating?

Re: Boring Python: Code quality

#47

Post by drcongo »

makapuf wrote: post #39
drcongo wrote: post #34

Earlier quoted context omitted.

> it doesn't work with tabs What do you mean by this? Are you indenting Python with tabs?

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.

Re: Boring Python: Code quality

#48

Post by bombolo »

kuu wrote: post #9
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…

> Black formats things differently depending on the version. Then add black as part of your environment with an specific version...

I'm sure you will get many contributions to your project if you refuse people with the wrong distribution from contributing.

Re: Boring Python: Code quality

#49

Post by bombolo »

fnord123 wrote: post #26
bombolo wrote: post #15

Earlier quoted context omitted.

Or wait until a more sensible formatting tool comes along. Reformatting the whole code every version isn't so good. It's also very slow.

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.

Re: Boring Python: Code quality

#50

Post by jsmeaton »

aitchnyu wrote: post #46

I wish VSCode would figure out that ExampleModel.objects.first() returns ExampleModel or None or ExampleModel.objects.filter() returns an iterable of ExampleModel. Has anybody gotten this working, automatically or manually annotating?

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

Post reply on HN