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

101–110 of 232 posts

Re: Boring Python: Code quality

#101

Post by ReflectedImage »

bombolo wrote: post #97
ReflectedImage wrote: post #90

Earlier quoted context omitted.

Unit tests test the parts of the library that are in use implicitly. As does integration testing, user acceptance testing and whole system testing (QA engineers, frontend testing, etc.) Nothing has been forgotten. Python isn't Java, nor should you develop your Python code as if it were Java. Python has it's own software development practices that take advantage of the language's strengths including dynamic typing. It…

> It you don't know how to work with a dynamically typed language properly, that's on you. And I guarantee you will get poor results pretending it's a statically typed language. Insulting me won't make you a better developer nor a better person :) Getting started with type hints is not easy, but it can be done incrementally and it is worth it. If you haven't used them, please learn before insulting people who are mor…

Using static typing in a dynamically typed language will always make you a poor software engineer who doesn't understand the tools they use nor the engineering trade-offs involved.

But sure continue to hammer in nails with a screwdriver, it's only your own time you are wasting.

And I've noticed you failed to provide any sources whatsoever for your nonsense.

Re: Boring Python: Code quality

#102

Post by progval »

bsdz wrote: post #43
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.

Black checks the AST, not the byte code.

Re: Boring Python: Code quality

#103

Post by MrJohz »

bombolo wrote: post #98
MrJohz wrote: post #94

Earlier quoted context omitted.

A lot of modern open source projects include a lock file or some other mechanism that ensures that all contributors use the same versions of certain key tools. Obviously there are still going to be some differences in the environment, but for things like formatting, linting, etc, it's generally fairly easy to lock down a specific version. In Python, the easiest way to achieve this is using Poetry, which creates a loc…

Using lock files is a good way to make sure your software never ends up in a distribution and in the hands of users.

The popular Rust tool "ripgrep" uses a lock file for development (you can see it in the GitHub repo), and yet is in the official repositories for homebrew, various Windows package managers, Arch, Gentoo, Fedora, some versions of openSUSE, Guix, recent versions of Debian (and therefore Ubuntu), FreeBSD, OpenBSD, NetBSD, and Haiku.

With all due respect, I don't think you're correct.

Re: Boring Python: Code quality

#104

Post by bombolo »

ReflectedImage wrote: post #99
bombolo wrote: post #96

Earlier quoted context omitted.

> Given that type hints are a new language feature in Python, please explain to me how these Python houses used static typing when type hints didn't exist? They've existed since 2015… please explain me how 2015 is "new"?

Python has been around since 1991. I'm little bit more experienced than you.

You seem to have no experience with type hints… You could have acquired this experience but didn't.

No shame, but you are not the most qualified person to comment on typing.

Also python3 is from 2008, and it's effectively a different programming language.

Re: Boring Python: Code quality

#105

Post by bombolo »

ReflectedImage wrote: post #101
bombolo wrote: post #97

Earlier quoted context omitted.

> It you don't know how to work with a dynamically typed language properly, that's on you. And I guarantee you will get poor results pretending it's a statically typed language. Insulting me won't make you a better developer nor a better person :) Getting started with type hints is not easy, but it can be done incrementally and it is worth it. If you haven't used them, please learn before insulting people who are mor…

Using static typing in a dynamically typed language will always make you a poor software engineer who doesn't understand the tools they use nor the engineering trade-offs involved. But sure continue to hammer in nails with a screwdriver, it's only your own time you are wasting. And I've noticed you failed to provide any sources whatsoever for your nonsense.

> And I've noticed you failed to provide any sources whatsoever for your nonsense.

As opposed to your 404 "peer reviewed paper"? :D

> Using static typing in a dynamically typed language will always make you a poor software engineer

Making broad statements about things you've never used yourself just makes you an arrogant guy on the internet who is quite likely to be a poor software engineer with a big ego.

Re: Boring Python: Code quality

#106

Post by ReflectedImage »

bombolo wrote: post #105
ReflectedImage wrote: post #101

Earlier quoted context omitted.

Using static typing in a dynamically typed language will always make you a poor software engineer who doesn't understand the tools they use nor the engineering trade-offs involved. But sure continue to hammer in nails with a screwdriver, it's only your own time you are wasting. And I've noticed you failed to provide any sources whatsoever for your nonsense.

> And I've noticed you failed to provide any sources whatsoever for your nonsense. As opposed to your 404 "peer reviewed paper"? :D > Using static typing in a dynamically typed language will always make you a poor software engineer Making broad statements about things you've never used yourself just makes you an arrogant guy on the internet who is quite likely to be a poor software engineer with a big ego.

I'm sure you could find it on Google Scholar. I'm not your personal googler.

My wages disagree with that statement. But hey, we can't all be 10x.

Did it ever occur to you to think about why people use scripting languages or what advantages they have over regular programming languages?

Of course not, you are used to statically typed languages and are blinded to the idea that there are other ways to develop software.

I'm guessing you did a search for sources to backup what you are saying and found out pretty quickly that they don't exist.

Static typing in Python is a practice based entirely in common ignorance not reality.

Re: Boring Python: Code quality

#107

Post by bombolo »

MrJohz wrote: post #103
bombolo wrote: post #98

Earlier quoted context omitted.

Using lock files is a good way to make sure your software never ends up in a distribution and in the hands of users.

The popular Rust tool "ripgrep" uses a lock file for development (you can see it in the GitHub repo), and yet is in the official repositories for homebrew, various Windows package managers, Arch, Gentoo, Fedora, some versions of openSUSE, Guix, recent versions of Debian (and therefore Ubuntu), FreeBSD, OpenBSD, NetBSD, and Haiku. With all due respect, I don't think you're correct.

And how much rust software is packaged in distributions? Almost none. They haven't figured out the procedures, because distributions really really don't want pinned stuff around.

Homebrew, windows, arch all have very very relaxed processes to enter. There is no QA, you can just do whatever you want. I mean more like Fedora and Debian.

Re: Boring Python: Code quality

#108

Post by dontlaugh »

drcongo wrote: post #92
gjulianm wrote: post #81

Earlier quoted context omitted.

Yes. The code started as being indented by tabs, so changing it now is a mess. Also, not to start a flamewar, but I've always preferred tabs to spaces in any language, I find them more reliable, easier to use...

Not going to argue about your personal preference, but in Python spaces for indentation isn't just a personal preference - you'll run into a fair amount of issues with that, this one being just the tip of the iceberg.

Not necessarily. Consistently indenting with tabs and aligning with spaces does work, but is tricky to enforce.

Re: Boring Python: Code quality

#109

Post by dontlaugh »

bombolo wrote: post #107
MrJohz wrote: post #103

Earlier quoted context omitted.

The popular Rust tool "ripgrep" uses a lock file for development (you can see it in the GitHub repo), and yet is in the official repositories for homebrew, various Windows package managers, Arch, Gentoo, Fedora, some versions of openSUSE, Guix, recent versions of Debian (and therefore Ubuntu), FreeBSD, OpenBSD, NetBSD, and Haiku. With all due respect, I don't think you're correct.

And how much rust software is packaged in distributions? Almost none. They haven't figured out the procedures, because distributions really really don't want pinned stuff around. Homebrew, windows, arch all have very very relaxed processes to enter. There is no QA, you can just do whatever you want. I mean more like Fedora and Debian.

The distros will eventually stop this dangerous practice of mixing and matching versions for all dependencies. It can only work for a small set of system components, which is what every other OS does.

Re: Boring Python: Code quality

#110

Post by adammarples »

bombolo wrote: post #68
adammarples wrote: post #30

Earlier quoted context omitted.

Just put a versioned black into pre-commit yaml and put that in your source and forget about it

So now we have one more (useless) build requirement for developers?

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.
Post reply on HN