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

121–130 of 232 posts

Re: Boring Python: Code quality

#121

Post by ReflectedImage »

bombolo wrote: post #116
ReflectedImage wrote: post #113

Earlier quoted context omitted.

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

It's called reading the libraries documentation.

Polyglot as in multiple programming languages.

I'm afraid it is true. Knowing the limitations of the tools you use is important. And you clearly do not.

Yes, I've done programing expensive networking hardware in C. I think you are missing that I know a lot more than you.

Tagged values aka dynamic typing is an excellent approach to doing a list from the developer's perspective.

If you think dynamic typing is like using void pointer in C you are very much mistaken.

Re: Boring Python: Code quality

#122

Post by bombolo »

dontlaugh wrote: post #109
bombolo wrote: post #107

Earlier quoted context omitted.

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.

It's more dangerous to let people pin dependencies and have vulnerable libraries in use forever.

Re: Boring Python: Code quality

#123

Post by bombolo »

burntsushi wrote: post #111
bombolo wrote: post #107

Earlier quoted context omitted.

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

> So you're just plain empirically wrong about lock files preventing Rust programs from being packaged.

My mistake, seems rust packagers gave up on decent packaging. It isn't so for the python policy, I can assure you :)

Re: Boring Python: Code quality

#124

Post by LtWorf »

_bohm wrote: post #85
LtWorf wrote: post #10

Earlier quoted context omitted.

Don't pin unless it's needed. I have a library… most downloaded version is 3 years old. The newer versions are massively faster but nobody uses them.

Agree in principle, but I'm giving advice to someone who programs on occasion and is primarily concerned with their programs breaking due to dependency version upgrades when they come back to them after a little while.

My advice would be to use stuff that is in distributions… it hopefully (not necessarily) is maintained by less noob people who don't break API all the time.

Re: Boring Python: Code quality

#125

Post by LtWorf »

anderskaseorg wrote: post #13
LtWorf wrote: post #10

Earlier quoted context omitted.

Don't pin unless it's needed. I have a library… most downloaded version is 3 years old. The newer versions are massively faster but nobody uses them.

You should not pin the public requirements that get uploaded with a library (listed in setup.py, setup.cfg, or pyproject.toml), since that will restrict your downstream users, leading to version conflicts and persistent security vulnerabilities. But it’s totally reasonable to pin the private requirements that you develop it against (listed in requirements.txt, poetry.lock, or similar), updating them every so often du…

So leaf packages can pin vulnerable or slow stuff why?

Re: Boring Python: Code quality

#126

Post by whalesalad »

jerrygenser wrote: post #84

Even since the start of python typing, it was recommended to use a more generic type like Iterable instead of List. The author claims that List is too specific -- this seems like a straw man argument against typing that doesn't acknowledge python's own advice. Also, mypy has gotten really good in recent years and I can vouch that on projects that have typing I catch bugs much much sooner. Previously I would only catc…

> Even since the start of python typing, it was recommended to use a more generic type like Iterable instead of List. The author claims that List is too specific

These statements contradict themselves? List is too specific, and Sequence[item] is preferred. Sometimes you are dealing with a tuple, or a generator, and so it makes more sense to annotate that it is a generic iterable versus a concrete list.

Re: Boring Python: Code quality

#127

Post by _8j50 »

black3r wrote: post #73
_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 cha…

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 all the deps. But what if your project is a library? That means all other libraries need to use the same or greater python version but what if your distro doesn't yet support the very latesr python version? It's such a nightmare.

New versions should come out no more often than every 3-4 years imho and even then every effort should be made to have those features backward compatible like have a tool that will degrade scripts to be usable on a previous language version.

Re: Boring Python: Code quality

#128

Post by jerrygenser »

whalesalad wrote: post #126
jerrygenser wrote: post #84

Even since the start of python typing, it was recommended to use a more generic type like Iterable instead of List. The author claims that List is too specific -- this seems like a straw man argument against typing that doesn't acknowledge python's own advice. Also, mypy has gotten really good in recent years and I can vouch that on projects that have typing I catch bugs much much sooner. Previously I would only catc…

> Even since the start of python typing, it was recommended to use a more generic type like Iterable instead of List. The author claims that List is too specific These statements contradict themselves? List is too specific, and Sequence[item] is preferred. Sometimes you are dealing with a tuple, or a generator, and so it makes more sense to annotate that it is a generic iterable versus a concrete list.

From the original article:

> 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. Yet the Python type-annotation ecosystem was strongly oriented around nominal typing (i.e., caring that something is exactly a list) from the beginning.

I'm saying that this quote is a straw man and that contrary to what is claimed in the quote, instead, the ecosystem would go with/recommend Iterable[Item] or Sequence[Item] and not List[Item] if applicable.

I think we both agree, not sure which part of my comment you think is contradictory.

Re: Boring Python: Code quality

#129

Post by trymas »

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.

TIL and seems very nice project.

Though their `v0.0.X` versioning is very funny to me (https://0ver.org/).

Re: Boring Python: Code quality

#130

Post by zzzeek »

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. So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth.

use pre-commit https://pre-commit.com/ so that everyone is on the same version for commits.

Post reply on HN