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

171–180 of 232 posts

Re: Boring Python: Code quality

#171

Post by bombolo »

adammarples wrote: post #110
bombolo wrote: post #68

Earlier quoted context omitted.

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.

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.

Re: Boring Python: Code quality

#172

Post by bombolo »

nxpnsv wrote: post #17
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…

Two developers on the same python project should also use the same version... with poetry it is straightforward to keep track of dev dependencies. Reorder python imports is an alternative for isort: https://github.com/asottile/reorder_python_imports

> Two developers on the same python project should also use the same version

Why? It is expected for the thing to run on different python versions and different setups… what's the point of forcing developers to a uniformity that will not exist?

It's actually better to NOT have this uniformity, so issues can get fixed before the end users complain about them.

Re: Boring Python: Code quality

#173

Post by bombolo »

timothycrosley wrote: post #148
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…

> 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 of behaviour from what it was doing before. This is not isort! isort has never done that. And it has a formatting guarantee across the major versions that it actively tests against projects online that use it on every sin…

It did this to me today…

Re: Boring Python: Code quality

#174

Post by bombolo »

BerislavLopac wrote: post #95
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…

> So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth. You should never develop using the system Python interpreter. I recommend pyenv [0] to manage the installed interpreters, with a virtual environment for the actual dependencies. [0] https://github.com/pyenv/pyenv

> You should never develop using the system Python interpreter.

Yes yes… never ever make the software run in a realistic scenario! You might end up finding some bugs and that would be bad! (I'm being sarcastic)

Re: Boring Python: Code quality

#175

Post by bombolo »

eesmith wrote: post #159
bombolo wrote: post #54

Earlier quoted context omitted.

As I said in other comments, if you try to force contributors to reproduce exactly your local setup, you will be left with no contributors. Which is why you set up a CI to run the tests… because people will most likely not. As for build times, it was an extreme example. But even an extra step taking 5 extra minutes is very annoying to me…

> if you try to force contributors to reproduce exactly your local setup, you will be left with no contributors. ... That's not been my experience. To the contrary, having a requirements.txt means your contributors are more likely to have a working environment, as when your package depends on package X but the contributor has a 5-year-old buggy version of X, doesn't realize it, and it causes your program to do the wr…

> How do black reformatting changes cause an extra 5 minutes?

Did you even read my comments?

Black reformatting causes more steps in bisecting. It's quite easy that a test suite takes 5+ minutes.

Re: Boring Python: Code quality

#176

Post by hbrn »

dragonwriter wrote: post #164
hbrn wrote: post #162

Earlier quoted context omitted.

What I meant is argument marked as Iterable is compatible with list being passed. > Iterable is better as an argument type unless you have a reason to force consumers to use lists See, I feel the exact opposite: I use Iterable only if I have a reason to force consumers to use Iterable. When you're marking argument as Iterable, how confident do you feel that you will never query collection size or access it by index?…

> See, I feel the exact opposite: I use Iterable only if I have a reason to force consumers to use Iterable. A broad argument type doesn’t force consumers not to use a narrower type. (It forces the implementer of the function to not rely on additional features of the narrower type, but if I am writing the function, I can be certain whether or not that is acceptable.) Meanwhile, using a narrower type than needed for a…

> Since all lists are Iterables but not all Iterables are lists, Iterables are necessarily more ubiquitous than lists.

Yeah, that's what I meant by being pedantic :)

Here's a question: you receive a JSON payload that contains a list. You will then pass this list to two functions, one of them only iterates, another one uses list interface (let's say checks length among other things). Should you mark the argument as a list, or as an Iterable in the first function?

Solely from the code perspective, it's definitely an Iterable. But in my mental model it still remains a list. I don't like it when code deviates from my mental model. Forcibly treating it as an Iterable only makes it more complicated, while not giving anything in return.

Sure, you could say that callee should not have expectations of the caller, but what if those functions are already coupled? They are in the same module, and argument names clearly denote a collection. The fact that in certain scenarios it is "technically Iterable" serves nothing but pedantic value.

Re: Boring Python: Code quality

#177

Post by bombolo »

IshKebab wrote: post #118
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.

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

why?

Do you hate terse diffs in git?

Re: Boring Python: Code quality

#178

Post by bombolo »

burntsushi wrote: post #154
sseagull wrote: post #142

Earlier quoted context omitted.

How Linux package managers handle these newer languages with their own package managers (including rust) is an ongoing pain point. Here’s an article from 2017 about it, and I don’t know if things have improved: https://lwn.net/Articles/712318/

I didn't say it wasn't a pain point or that there weren't challenges. I said I don't hear about people complain about how Rust programs are packaged. Not that the packaging of Rust programs (among others) itself doesn't present interesting challenges depending on the policies of a particular distro. Archlinux, for example, has far fewer problems than Debian because of differences in policy. The poster I was respondin…

I contribute to packaging. But thanks for teaching me about something I know already.

Now try to get something using an obsolete version of some python module into Fedora or Debian and let me know how it goes… It would not be accepted as it is. It'd be patched to work with a current one or just rejected.

Re: Boring Python: Code quality

#179

Post by mmcnl »

liendolucas wrote: post #150
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…

> The other thing typing does is allow for refactoring code. No. What allows you confident refactoring code are automated tests. I honestly can't understand why people are so obsessed about types, especially in languages like Python or Javascript.

Shorter feedback loops = increased productivity.

Re: Boring Python: Code quality

#180

Post by bombolo »

hbrn wrote: post #135
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…

> most common reason for using static typing is to allow the codebase to be a monolith like it's still the 90s This is so true. Static typing shines when you have a very complicated deeply nested system. And that's what most teams are naturally end up creating. But how about not building the complicated system in the first place? Most of complexity in modern software is accidental.

> But how about not building the complicated system in the first place?

"For every complex problem, there's a solution that is simple, neat, and wrong."

Post reply on HN