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

71–80 of 232 posts

Re: Boring Python: Code quality

#71

Post by ReflectedImage »

bombolo wrote: post #65
ReflectedImage wrote: post #61

Earlier quoted context omitted.

Anyone with experience of writing both dynamic typed and statically typed can tell you that. Infact, you could just try it out for yourself. But here is your internet source for this blatantly obvious fact: https://games.greggman.com/game/dynamic-typing-static-typing...

I do have such experience and I really can't tell that. Which is why I wondered if anyone else was in fact saying that. > But here is your internet source for this blatantly obvious fact: https://games.greggman.com/game/dynamic-typing-static-typing ... Ah no I meant a proper peer reviewed source. The claim that untyped code has fewer bugs is completely bonkers, so I was quite sure that no such source existed. Why do…

"The claim that untyped code has fewer bugs is completely bonkers"

There are plenty of academic sources that will tell you that the number of bugs in a program is directly proportional to the number of lines in the program and static typing has no effect on this.

https://stackoverflow.com/questions/2898571/basis-for-claim-...

Additionally, statically typed code involves large amounts of boilerplate code in the form of abstract base classes, interfaces, generics, templating, etc. It's a very verbose code style.

It's your turn, find an academic source to backup your claim that static typing reduces the number of bugs. Cause it just isn't true.

Microsoft, google and Facebook have a lot of programmers coming from languages with static typing and want to make Python more familiar.

It's a far distance away from anything resembling good practice.

Actual Python houses typically don't use static typing.

Re: Boring Python: Code quality

#72

Post by 411111111111111 »

nine_k wrote: post #66
dustrider wrote: post #44

Earlier quoted context omitted.

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.

We have Black as a pre-commit hook; works fine, even if it disagrees with your IDE a little bit sometimes. CI/CD has no business changing your code; it builds stuff using it, exactly as if commit such-and-such.

> CI/CD has no business changing your code; it builds stuff using it, exactly as if commit such-and-such.

That going too far unless you define code to be a subset of the files checked into the repository and simply define any file that's touched in an automated manner to be not code

There are a lot of useful automations that can be part of the CI/CD pipeline, such as increasing a version number, generating a changelog, creating new deployment configuration etc

They don't have to be part of it and it's possible to work around it/don't commit... But that comes with it's own challenges and issues

Re: Boring Python: Code quality

#73

Post by black3r »

_8j50 wrote: post #4

I don't work on large python projects, mostly just small scripts that need to work well (integrating with a 3rd party rest api is a good example). I don't do CI or unittests but I use git. This is because it takes time and honestly no one outside of myself would care for small stuff like that. But I do run autopep8 and pylint it (I ignore stuff like line being too long,broad exception handling or lack of docs). My co…

> I love python but this is exactly why I prioritize languages that don't churn out new drastic features quickly.

What do you mean by "drastic" features "quickly"? Python releases new version once a year these days, and upgrading our Django-based source code with 150 dependencies from 3.4 to 3.11 literally meant switching out the python version in our CI configuration and README.rst every once in a while, no code changes were necessary for any of those jumps...

Our developer README also contains a guide how to set-up and use pyenv and it's virtualenv plugin which makes installing new python versions and managing virtualenvs easy, just pyenv install, pyenv virtualenv, pyenv local, and your shell automatically uses the correct virtualenv whenever you're anywhere inside your project folder...

jumping to python3 was big, but you had plenty of time to prepare for that and plenty of good utilities to make the jump easier (2to3, six, ...). python2.7 itself was released 18 months after python3.0, and by the time python2.7's support ended, python3.8 was already out...

Re: Boring Python: Code quality

#74

Post by modeopfer »

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. I switched because it felt way to heavy for porting scripts and small applications to constrained devices like a Raspberry Pi.

And then there are also Docker Images, which I use if I want to give an application to somebody that "just works".

What's your method of choice?

[0] https://python-poetry.org/

[1] https://www.anaconda.com/

Re: Boring Python: Code quality

#75

Post by Lutger »

tasuki wrote: post #36
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.

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 metric, since you likely already know that.

The metric 'coverage' is almost useless. Code coverage starts to be useful once you let go of it as a goal and ignore the total percentage number. I found it is very useful though if you can generate detailed reports on each line of code or better yet, each branch in the code, indicating whether that line or branch is tested. Eyeball all the lines which don't have tests and ask yourself: would it be useful to add a test exercising this codepath? How do I make sure it works and what cases can I think of that could go wrong? This doesn't automatically lead to good tests, but it helps you spot where you should focus your testing efforts.

Code coverage is a good tool to help think of test cases, as a metric for the total codebase it is nearly useless.

Re: Boring Python: Code quality

#76

Post by wil421 »

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

>I switched because it felt way to heavy for porting scripts and small applications to constrained devices like a Raspberry Pi.

Agreed. I like docker images for smallish portable scripts. At home I can develop on my Mac and port it to a Raspberry PI or another x86 Windows/Linux box.

Planning on running a docker swarm with a few Pi’s to see how it works.

Re: Boring Python: Code quality

#77

Post by Smotko »

jkukul wrote: post #51
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 Blac…

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

Re: Boring Python: Code quality

#78

Post by gjulianm »

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

I use pip-tools to build a requirements.txt file from a requirements.in file. It does basically the same as poetry, but more manually. For me that's good because one of the application has a lot of requirements, and it needs to be deployed on systems with different Python versions, and the requirements need to be packaged along with the application because the servers have very limited internet access. So as long as Poetry doesn't add good support for multiple python versions and/or easy packaging of all dependencies, it isn't worth it for me to do the migration.

Re: Boring Python: Code quality

#79

Post by gjulianm »

anderskaseorg wrote: post #28
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, as of last month. I’m not sure if it works with YAPF; it’s designed to work with Black and doesn’t currently have many of isort’s configuration options. Worth a try!

Thanks! The configuration options don't matter too much, I was really unhappy with the options isort gives.

Re: Boring Python: Code quality

#80

Post by TomSwirly »

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…

My current project is my first project in a while which does not use black.

I liked black, though I was never satisfied with the fact that there was no way to normalize quotes to be single quotes: '. Shift keys are hard on your hands, so avoiding " makes a lot of sense to me. But there's the -S option that simply doesn't normalize quotes so it has never been a real issue.

However, this new project has a lot of typer functions with fairly long parameter lists (which correspond to command line arguments so they can't be broken up).

black reformats these into these weird blocks of uneven code that are very hard to read, particularly if you have comments.

Everyone is a fan of black; no one liked the result. :-/

I have a key in my editor to blacken individual files, but we don't have it as part of our CI. Perhaps next project again.

Post reply on HN