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

221–230 of 232 posts

Re: Boring Python: Code quality

#221

Post by bombolo »

IshKebab wrote: post #215
bombolo wrote: post #208

Earlier quoted context omitted.

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

> Why would it cause extra effort?

As I said… because a 1 word change easily ends up changing multiple lines and from the diff it's not clear it's just a 1 word change. So… extra effort.

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

No I don't. My release branch and old-release branch use different versions. Such a thing would need to understand which base branch I'm working on, or recreate the venv continuously.

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

Seems to me you don't support older versions, in which case everything is easy.

Re: Boring Python: Code quality

#222

Post by ReflectedImage »

bombolo wrote: post #199
ReflectedImage wrote: post #187

Earlier quoted context omitted.

You literally told me that you are a cargo cultist and your words should not to be listened to in your previous comment. No one who has really tried both would conclude that static typing is better hence I know you are lying. :p

> You literally told me that you are a cargo cultist and your words should not to be listened to in your previous comment. I did no such thing. But after hours of you writing lies, I'm not surprised you wrote another one. > No one who has really tried both would conclude that static typing is better hence I know you are lying. :p In 10-15 years, when you will actually have some non-made-up programming experience, you…

I don't remember writing any lies. Additionally, we can just read what you read several comments ago. So what do you think you are playing at?

Nah, I'm more qualified than you. You just don't want to hear that you are wrong.

Re: Boring Python: Code quality

#223

Post by _8j50 »

black3r wrote: post #193
_8j50 wrote: post #127

Earlier quoted context omitted.

Firsr, to this date, stuff I absolutley need that is in 2.7 i have to either try to fix or venv or somehow get it to work is one of my biggest headaches (Not my code). Second, yes, all you have to do is switch out the python version to upgrade but let's say you start using f-strings that means all of your users (doesn't apply to django since it is server software) have to upgrade to the right python version including…

> Firsr, to this date, stuff I absolutley need that is in 2.7 i have to either try to fix or venv or somehow get it to work is one of my biggest headaches (Not my code). 2.7 was supported for 10 years and it's support ended 2 years ago. There's been ample time to upgrade the code or look for an alternative. If I "absolutely needed" to use a piece of code that I didn't write, is for an unsupported platform and is itse…

> ...I'd absolutely find the time for it. As a developer if I use a library that...

Like I said, my day job isn't being a dev which means time for that is rare.

Languages are not user software, they should never be deprecated. I get deprecating standard libraries bur under no context is it ok to deprecate a whole language. Yoh can freeze development and only perform security updates to the interpreter but there is no need to deprecate a language. It is a betrayal of the trusr users put into python when they invested time on it and this is exactly what I mean by avoiding rapidly changing languages. They don't care one bit that people are using their language, they treat like any other software that gets supported and discarded. C89 is still supported! People write new stuff with it. You know why? Because there is nothing to support, just parsing and compiling of a langauge. No new features need to be developed and bugs should be accepted instead of fixed. The interpreter should be available for download and use on any platform for as long as even one guy is using the language.

> you're probably on a very old distro.

Maybe, I usually go for debian but I have run into this issue and it becomes a dependency nightmare on anything that needs the old python version (in the package manager dependency resolver not in python).

> If new versions came out every 3-4 years, that would mean they would have more drastic changes

That's fine, because there would be less versions. All changes are drastic changes from the perspective of someone that is having to google random python errors to figure out what broke and how to fix it. At least it won't be a constant nightmare fixing problems made by the langauge itself in addition to the 3rd party code and your own code. The frequency of how many bugs you have causes by those 3 cause categories should in that increasing frequency. I should not have lnaguage version bugs more often than bugs in my own code.

> But in the end, it doesn't really matter how often a new version comes out but rather how long the old versions should be supported, right? And I think it's up to the library authors to decide how long to support older versions

It does matter because most devs that code for a living like to tinker with new flashy versions so each version of a library they release is that much more prone to requiring newer python versions. The less frequent python releases, the more they will use the current python features before introducing version breaks.

I really think it is a developer culture problem at the end of the day where because you are writing foss code, you don't care about the experience of those who depend on your code.

Re: Boring Python: Code quality

#224

Post by stinos »

stinos wrote: post #216
captnswing wrote: post #89

Earlier quoted context omitted.

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?

Ok apparently it does: https://github.com/charliermarsh/ruff#how-does-ruffs-import-...

Re: Boring Python: Code quality

#225

Post by eesmith »

bombolo wrote: post #219
eesmith wrote: post #213

Earlier quoted context omitted.

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

> and don't really have a product that is released to customers who pay to support old versions for years

My main product is 12 years old, with paying support customers, and with bugfix branches for older releases.

> just to re-run black and isort to backport a fix to a release branch

Great! That's an excellent reason. But it has nothing to with bisection.

Re: Boring Python: Code quality

#226

Post by UncleMeat »

ReflectedImage wrote: post #71
bombolo wrote: post #65

Earlier quoted context omitted.

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

Not across different languages. Create a new version of Java that requires an empty line between each line containing text and bugs won’t double.

Re: Boring Python: Code quality

#227

Post by bvrmn »

hbrn wrote: post #140
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.

> It's easy and rises code quality Absolutely not. This leads to testing being invasive and driving the design of your software, usually at the cost of something else (like readability). Testing is a tool, you can't let it turn into a goal.

Could you elaborate with python-oriented examples? I tend to agree for static typing languages like Java — to fully test you have to go a total DI path. It leads to bloat and additional layers. I don't see anything similar for python because you have to do nothing to bring your code into a test environment.

> Testing is a tool, you can't let it turn into a goal.

Yep, and I use testing as a tool to be sure we ship quality code. It's 2x important for our case, we don't have control on hosts where our product is run and 100% coverage was a salvation. We even start to ship new versions without any manual QA.

Re: Boring Python: Code quality

#228

Post by bvrmn »

hbrn wrote: post #141
Lutger wrote: post #75

Earlier quoted context omitted.

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.

Funny thing that 100% coverage really helps for dynamic typed languages. It's easy and helpful.

Re: Boring Python: Code quality

#229

Post by adammarples »

bombolo wrote: post #171
adammarples wrote: post #110

Earlier quoted context omitted.

pre-commit is very useful, in my opinion. When organising code from a lot of Python developers at least, getting the boring stuff like formatting, import ordering, linting, mypy etc. sorted is a time saver.

Do you know how slow all of that is? Do you want to run all of that per every commit? The result would be people making a monocommit rather than incremental commits that is easy to review one by one.

Yes, so fast that it makes no difference at all to me. How slow do you think black is?

Re: Boring Python: Code quality

#230

Post by timothycrosley »

bombolo wrote: post #206
timothycrosley wrote: post #181

Earlier quoted context omitted.

Are you using any custom settings?

No. Seems they changed the default ordering

Hi! I said this with more certainty than I should have. Software can always have bugs! For reference, I wrote isort, and my response came from the perspective that I have certainly worked very hard to ensure it doesn't have any behavior that is random or non-deterministic. From your description, it sounds like someone may have turned on force-alphabetical-sort (if this is in a single project). See: https://pycqa.github.io/isort/docs/configuration/options.htm.... You can do `isort . --show-config `, to introspect the config options isort finds and where it finds them from within a project directory. The other thing I could think of, is coming from isort 4 -> 5, I wouldn't think it would fully ignore import groupings, but maybe it doesn't find something it used to find automagically from the environment for determining a first_party import. If that's the case this guide may be helpful: https://pycqa.github.io/isort/docs/upgrade_guides/5.0.0.html. If none of this helps, I'd be happy to help you diagnose what your seeing.
Post reply on HN