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

161–170 of 232 posts

Re: Boring Python: Code quality

#161

Post by rirze »

modeopfer wrote: post #74

What's the current state of the art of managing multiple virtual environments, running tests and running your application? On Ubuntu and Windows I use Poetry [0], and it works, although it has (had?) some quirks during the installation on Windows. I liked its portability and lockfile format though. A few years ago I used conda [1], which was nice because it came batteries included especially for Deep Learning stuff.…

I'm liking PDM for a while now. Quicker than Poetry and built according to the Python package spec in mind and not as an afterthought. While it was originally meant to work with PEP 582, it works with virtual environments too (now default).

https://github.com/pdm-project/pdm

Re: Boring Python: Code quality

#162

Post by hbrn »

dragonwriter wrote: post #157
hbrn wrote: post #144

Earlier quoted context omitted.

Iterable is an import away, while list is already at my fingers. There's zero harm in using list in private interfaces: I know I'm the only one passing the value, I know it is always a list. As an argument type, Iterable is compatible with list, so it's benefits are minimal (with rare exceptions). Lists are easier to inspect in a debugging session. Iterable can be useful as return type, because it limits the interfac…

> As an argument type, Iterable is compatible with list, so it’s benefits are minimal (with rare exceptions). Iterable is not compatible with list, but list is compatible with iterable. As the more general type, Iterable is better as an argument type unless you have a reason to force consumers to use lists. Even in private interfaces, I tend to prefer it, because I often end up wanting to pass something constructed o…

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?

I understand the desire to limit the interface and YAGNI, but since lists are more familiar and ubiquitous, using Iterable feels more complicated and unnecessarily pedantic.

Re: Boring Python: Code quality

#163

Post by jerrygenser »

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.

It's not just about types. It's about having interfaces I should expand on. And, I'm assuming there are automated tests, otherwise and typing is additive. I should clarify that it's also having defined interfaces using the type system to do it.

By depending on interfaces/abstractions instead of specific cases you can refactor the interface and not break clients. It's very difficult to do this unless you have types.

This is something that Go is really good at and encourages but can be done with python/js on top of their type systems.

Re: Boring Python: Code quality

#164

Post by dragonwriter »

hbrn wrote: post #162
dragonwriter wrote: post #157

Earlier quoted context omitted.

> As an argument type, Iterable is compatible with list, so it’s benefits are minimal (with rare exceptions). Iterable is not compatible with list, but list is compatible with iterable. As the more general type, Iterable is better as an argument type unless you have a reason to force consumers to use lists. Even in private interfaces, I tend to prefer it, because I often end up wanting to pass something constructed o…

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 an argument does impose additional, unnecessary constraints on the consumer.

> When you're marking argument as Iterable, how confident do you feel that you will never query collection size or access it by index?

Absolute certainty, since I know what the function does and what I need to do it.

> I understand the desire to limit the interface and YAGNI, but since lists are more familiar and ubiquitous, using Iterable feels more complicated and unnecessarily pedantic.

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

Re: Boring Python: Code quality

#165

Post by tmh88j »

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.

> I honestly can't understand why people are so obsessed about types,

Types in Python feel like an added layer of confidence that my code is structured the way I expect it to be. PyCharm frequently catches incorrect argument types and other mistakes I've made while coding that would likely result in more time spent debugging. If you don't use any tools that leverage types you won't see any benefit.

Re: Boring Python: Code quality

#166

Post by LtWorf »

burntsushi wrote: post #133
bombolo wrote: post #122

Earlier quoted context omitted.

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

Who says the distros are using the lock file? AFAIK, Debian doesn't use ripgrep's lock file, for example. They don't have to, because of semver.

What's the point of the lockfile then?

Re: Boring Python: Code quality

#167

Post by bombolo »

ReflectedImage wrote: post #121
bombolo wrote: post #116

Earlier quoted context omitted.

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

> It's called reading the libraries documentation.

You ever tried to read haskell's documentation? You search functions by their type signature.

> Polyglot as in multiple programming languages.

lol ok.

> I'm afraid it is true. Knowing the limitations of the tools you use is important.

I agree. But to know the limitations one must know the tools first.

> And you clearly do not.

Having used both things gives me more knowledge than NOT having used both things.

> I've done programing expensive networking hardware in C.

I don't think expensiveness of the rig and skill correlates… are iphone developers better than android developers because iphones cost more?

> I think you are missing that I know a lot more than you.

Ah yes a "polyglot" who speaks just english. A true renaissance man.

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

It's kinda-like-it, conceptually. I've written a compiler and an interpreter, I know how they work.

Re: Boring Python: Code quality

#168

Post by burntsushi »

LtWorf wrote: post #166
burntsushi wrote: post #133

Earlier quoted context omitted.

Who says the distros are using the lock file? AFAIK, Debian doesn't use ripgrep's lock file, for example. They don't have to, because of semver.

What's the point of the lockfile then?

For people that want to build with the exact set of dependency versions tested by upstream. Just because some distros don't use them doesn't mean there isn't any point.

Re: Boring Python: Code quality

#169

Post by bombolo »

ReflectedImage wrote: post #138
bombolo wrote: post #112

Earlier quoted context omitted.

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

"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." Basically, you are saying you are a cargo cultist rather than a serious software developer. You fail to understand that the software practices of large multi-national companies are rarely good. Good luck flying your plane: https://www.abyssapexzine.com/2020/03/cargo-cul…

> Basically, you are saying you are a cargo cultist rather than a serious software developer.

No. I'm saying I tried both ways and I know advantages and disadvantages and I'm capable of deciding by myself.

You on the other hand did not try both but feign expertise.

> Good luck flying your plane: https://www.abyssapexzine.com/2020/03/cargo-cult/

Yes everybody knows what a cargo cult is. It's not some sort of intellectual remark. More of a random thing to say on the internet when you have no real arguments.

But good to know you can find sources… when they happen to exist :)

Re: Boring Python: Code quality

#170

Post by bombolo »

fnord123 wrote: post #117
bombolo wrote: post #49

Earlier quoted context omitted.

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.

I understood but I disagree.
Post reply on HN