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

111–120 of 232 posts

Re: Boring Python: Code quality

#111

Post by burntsushi »

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.

Bottom line is that the lock file in ripgrep's repo hasn't prevented it from being packaged. And I haven't heard of any distro maintainer complain about any lock file in any Rust program ever. So you're just plain empirically wrong about lock files preventing Rust programs from being packaged.

You've now moved on to talking about something else, which is "how much Rust software is packaged." Well, apparently enough that Debian has Rust packaging policy[1]. I'll give you one guess at what isn't mentioned in that policy. Give up? Lock files!

[1]: https://wiki.debian.org/Teams/RustPackaging/Policy

Re: Boring Python: Code quality

#112

Post by bombolo »

ReflectedImage wrote: post #106
bombolo wrote: post #105

Earlier quoted context omitted.

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

Your "sources" were a blog with opinions based on questionable statistics methods and a stackoverflow with a 404 link.

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

Just a hint: this screams insecurity.

Wealth does not correlate with knowledge.

Especially since you don't even use type hints, so you have no professional experience with them. Just an ill formed opinion by reading blogs and comments.

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

No compilation time? Very complete standard library? Opt-in typing? Good introspection? Numpy?

> 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 was doing python long before type hints existed, and I assure you they are an advantage. Now, I understand you lack the expertise to realise that. I'm just saying that insulting me won't make you correct.

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

I did not bother. The fact that microsoft, google and facebook invest money into it is proof enough. You reject it because you're being irrational.

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

I wish I could sound so bold and certain when being wrong!

Re: Boring Python: Code quality

#113

Post by ReflectedImage »

bombolo wrote: post #104
ReflectedImage wrote: post #99

Earlier quoted context omitted.

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.

I have experience in working on statically typed Python codebases, it's just obviously inferior.

I'll go further and tell you the most common reason for using static typing is to allow the codebase to be a monolith like it's still the 90s. You shouldn't be trying to build a monolith in a scripting language it's a recipe for disaster.

I'm a polyglot, I'm exactly the sort of person who should be commenting.

Does it surprise you that static typing is often a poor choice?

Static typing is something to be used when the performance of your code is important. I've done 40 Gbits/sec network traffic processing, certainly static typing is used for that.

Your standard business CRUD app? Usually dynamic is the better choice.

Re: Boring Python: Code quality

#114

Post by aitchnyu »

jsmeaton wrote: post #50
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

Could you share a guide on that?

Re: Boring Python: Code quality

#115

Post by indymike »

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…

> Not sure if I like the recommendation to not let Black change your code and just give out errors.

Let black format code before it is checked in. Code should not be reformatted for CI or production, and bad formatting should either ALWAYS throw errors (no known defects allowed) or NEVER throw errors (if it passes tests & runs ship it). Consistency is the key.

Re: Boring Python: Code quality

#116

Post by bombolo »

ReflectedImage wrote: post #113
bombolo wrote: post #104

Earlier quoted context omitted.

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.

I have experience in working on statically typed Python codebases, it's just obviously inferior. I'll go further and tell you the most common reason for using static typing is to allow the codebase to be a monolith like it's still the 90s. You shouldn't be trying to build a monolith in a scripting language it's a recipe for disaster. I'm a polyglot, I'm exactly the sort of person who should be commenting. Does it sur…

> I have experience in working on statically typed Python codebases, it's just obviously inferior.

Maybe they just were inferior projects?

I've used a library where every function just accepted "args, *kwargs" and no documentation was given. In that case it's not really the fault of the language that it sucks. It could be a similar case for you.

> I'm a polyglot, I'm exactly the sort of person who should be commenting.

Ok I speak 3 languages fluently and 1 more so-so… But what does this have to do with python typing????

In fact most people who study literature and languages don't know much about python types.

> Does it surprise you that static typing is often a poor choice?

No because it isn't true.

> Static typing is something to be used when the performance of your code is important.

We can all agree that python isn't something to use when performances are very important.

> Your standard business CRUD app? Usually dynamic is the better choice.

Ok. That's not what I do though.

Have you done any C and C++? You know how people prefer doing a list in C++ with a template rather than a list of void in C? Same thing in python. But perhaps you haven't experience in this field either?

Re: Boring Python: Code quality

#117

Post by fnord123 »

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.

I think you haven't understood what I've told you. Please look into pre-commit and using it.

Re: Boring Python: Code quality

#118

Post by IshKebab »

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…

What's the alternative? YAPF is even worse - it will flip flop between styles even on the same version! Its output is much less attractive, and there are even some files we had to whitelist because it never finishes formatting them (Black worked fine on the same files).

Not using a formatter at all is clearly worse than either option.

Re: Boring Python: Code quality

#119

Post by jmduke »

tilschuenemann wrote: post #24

There is also a 'hypermodern' cookie cutter template for python projects - I've used it several times now and it works mostly out of the box: https://github.com/cjolowicz/cookiecutter-hypermodern-python

I love this template as well, and wholeheartedly recommend it. There are a couple things you probably don't need (click and nox, for instance, seem only useful if you're really building a couple specific things) but the gestalt of it is really strong. The [article series](https://medium.com/@cjolowicz/hypermodern-python-d44485d9d76...) that spawned the template is worth reading in full.

I would go so far as to say that the hypermodern template, nomenclature aside, is strictly better than the recommendations that the OP put forward both here and in the previous essay on dependency management. Poetry and ruff, for instance, are both very good tools — and I can understand _not_ recommending them for one reason or another but to not even mention them strikes me as worrisome.

Re: Boring Python: Code quality

#120

Post by IshKebab »

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

Terrible advice not to use type hints and this reason makes no sense. There's already pretty good support for Sequence and Iterable and so on, and if you run into a place where you really can't write down the types (e.g. kwargs, which a lot of Python programmers abuse), then you can use Any.

Blows my mind how allergic Python programmers are to static typing despite the huge and obvious benefits.

It's true that Python's static typing does suck balls compared to most languages, but they're still a gazillion times better than nothing, and most of the reason they suck so much is that so many Python developers don't use them!

Post reply on HN