Live data from Hacker News

Learning Go as a Python Developer: The Good and the Bad

new.pythonforengineers.com

201–210 of 269 posts

Re: Learning Go as a Python Developer: The Good and the Bad

#201
post #179

Earlier quoted context omitted.

If I did that I'd have no harddrive space left due to how large python dependencies are.

Wat? What dependencies? I have right now 100 separate Python projects which each have their own venv, their own isolated dependencies, and their own isolated copy of Python itself and my code dir doesn’t even crack top 10 hard drive space.

Machine learning packages like Tensorflow can result in GB size package directories.

Re: Learning Go as a Python Developer: The Good and the Bad

#202
post #153
post #120

Earlier quoted context omitted.

Keep in mind that Python is 31 year old (it's even older than Java) it was created around the same time as world wide web. So it started when no one even knew they would need dependency management and evolved over time from people posting packages on their home pages, to a central website to what we now call PyPI. Similarly the tooling and way of packaging the code evolved. What you described are multiple tools that…

Being 31 years old doesn't preclude having a decent, official and reproducible way of installing packages in 2022. That's just a bad excuse to justify subpar package managers and terrible governance around this problem. Package management is pretty much a solved problem, no matter how old is your language. It smells to an outsider like me like a lot of bike-shedding and not enough pragmatism is going on in Python lan…

Yup. Java is 27 years and has a splendid package management system (Maven Central) which is so well designed that you can use it from two different tools that are extremely different (Maven and Gradle).

Re: Learning Go as a Python Developer: The Good and the Bad

#203

>sharing your code is even pain with colleagues even if they are using the same operating system, mainly because the Python requirement file doesn't pin dependencies, wat? Pretty sure you can use == in requirements.txt Also, its very possible, and quite easy to just include the code for the library in your package, which effectively "locks in" the version. We did this all the time when building AWS lambda deployments…

This comment section itself clearly shows how crazy dependency and environment management is in Python. In this thread alone, we've received instructions to... - poetry - "Just pin the dependencies and use Docker" - pip freeze - Vendoring in dependency code - pipreqs - virtualenv This is simply a mess and it's handled much better in other languages. I manage a small agency team and there are some weeks where I feel l…

When I tried learning Python, this mess is what turned me off so badly. Python is the first language I ever came across where I felt like Docker was necessary just to keep the mess in a sandbox.

Coming to that from hearing stories that there was supposed to be one way to do everything disenchanted me quickly.

Re: Learning Go as a Python Developer: The Good and the Bad

#204
post #172
post #153

Earlier quoted context omitted.

Being 31 years old doesn't preclude having a decent, official and reproducible way of installing packages in 2022. That's just a bad excuse to justify subpar package managers and terrible governance around this problem. Package management is pretty much a solved problem, no matter how old is your language. It smells to an outsider like me like a lot of bike-shedding and not enough pragmatism is going on in Python lan…

But Python has a decent and a reproducible way of installing packages. The problem python has is that things evolved over time, so you can find on the net plenty of outdated information. There is also a lot of blogs and articles with bad practices, most written by people that got something working. I think also a lot of issues with packaging is ironically because of PyPA that supposed to work on a standard, but in re…

I think we can get a good package management system for Python if we get rid of PyPA.

Re: Learning Go as a Python Developer: The Good and the Bad

#205
post #184
post #174

Earlier quoted context omitted.

I really like the walrus operator. It's helped me to create more straightforward if/elif blocks and loops. Effective python has some pretty good examples. https://effectivepython.com/2020/02/02/prevent-repetition-wi...

This really isn't a good argument though: it's an extra, extremely specific use case for assignment that looks visually very similar. And worse, effects code maintainability - if you need that assignment higher up, you're now editing the if statement, adding an assignment, plus whatever your interstitial code is. Python doesn't have block scoping so the argument for it is weak.

An example where I have wanted this many times before it existed is in something like:

while (n := s.read(buffer)) != 0:

    #do something with first n bytes of buffer
Without the walrus operator you either have to duplicate the read operation before the loop and at the end of the loop, or use while True with a break if n is zero. Both of which are ugly IMO.

Re: Learning Go as a Python Developer: The Good and the Bad

#206
post #179

Earlier quoted context omitted.

If I did that I'd have no harddrive space left due to how large python dependencies are.

Wat? What dependencies? I have right now 100 separate Python projects which each have their own venv, their own isolated dependencies, and their own isolated copy of Python itself and my code dir doesn’t even crack top 10 hard drive space.

[deleted]

Re: Learning Go as a Python Developer: The Good and the Bad

#207

Earlier quoted context omitted.

WSL is a fully fledged VM under the hood, it's just well integrated.

MS call it a "lightweight utility virtual machine", and "not a traditional VM experience", whatever that means. Docker also works on MacOS, with a basic linux distro running under hypervisor that again, I'm not sure qualifies as a 'fully fledged VM' (at least in terms of user access to it).

WSL, starting with v2, is a fully fledged virtual machine, and comes with its own built in Linux kernel. The 'lightweight' part is because resource allocation is bit more dynamic than your usual VirtalBox VM. Other than that, there is no difference.

Re: Learning Go as a Python Developer: The Good and the Bad

#208
post #161

Earlier quoted context omitted.

Haven't had any issues in Go so far.

As soon as you take 2 dependencies in any language, there's a chance you will not be able to upgrade both of them to latest versions because somewhere in the two dependency subgraphs there is a conflict. There's no magic to avoid this, though tooling can help find potentially working versions (at least by declaration). It's often the case that you don't encounter conflicts in Python or other languages, but I don't im…

Rust can include different versions of the same library (crate) in a single project just fine. As long as those are private dependencies, no conflicts would happen. A conflict would happen only if two libraries pass around values of a shared type, but each wanted a different version of the crate that defines the type.

I can't see a reason why Go would be different.

Re: Learning Go as a Python Developer: The Good and the Bad

#209

>sharing your code is even pain with colleagues even if they are using the same operating system, mainly because the Python requirement file doesn't pin dependencies, wat? Pretty sure you can use == in requirements.txt Also, its very possible, and quite easy to just include the code for the library in your package, which effectively "locks in" the version. We did this all the time when building AWS lambda deployments…

This comment section itself clearly shows how crazy dependency and environment management is in Python. In this thread alone, we've received instructions to... - poetry - "Just pin the dependencies and use Docker" - pip freeze - Vendoring in dependency code - pipreqs - virtualenv This is simply a mess and it's handled much better in other languages. I manage a small agency team and there are some weeks where I feel l…

The core problem with Python dependencies is denial. There are tons of people who make excuses for a system that is so bad Randall Munroe declared his dependencies a “superfund site” years ago. In a good ecosystem, that comic would have prompted change. Instead, it just prompted a lot of “works for me comments”. Monads are just monoids in the category of endofunctors, and C just requires you to free memory at the right time. Python dependencies just work as long as you do a thing I’ve never seen my colleagues do at any job I’ve worked at.

Re: Learning Go as a Python Developer: The Good and the Bad

#210
post #17

Earlier quoted context omitted.

What if the depedencies you pinned have non-pinned depedencies? packageA==1.0.0 depends itself on packageB Therefore, you can find yourself with a different set of deps. Had a bug like this once.

Pip freeze will pin explicit as well as transitive dependencies

This is not actually true. :-) Pip will install transitive deps from a requirements file unless you add the “no deps” flag. Pip freeze doesn’t pin anything. It just dumps stuff into a text file. If it’s a complete list, it has the side effect of pinning, but that’s not guaranteed by pip freeze in any way.
Post reply on HN