Live data from Hacker News

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

new.pythonforengineers.com

221–230 of 269 posts

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

#221

>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 is wrong and OMG all other 15 answers to this comment even more wrong.

Pinning a dependency in requirements.txt does not pin its transitive dependencies.

This does NOT mean you should pip freeze everything into requirements.txt, because then how do you distinguish top level dependencies from transitive?

The correct answer is to use lock file. No third party tools needed (1). In Python they named it constraints and requires an extra flag to use. pip freeze > constraints.txt. Then next time pip install -r requirements.txt -c constraints.txt.

Oh, and always always always use a venv for each project. Globally installed packages is a recipe for disaster.

(1) Poetry and Pipenv are still nice additions, with nicer project declarations in pyproject.toml and to save you from remembering pip flags or forgetting activation of venvs. But they are not strictly necessary and it’s honestly just 2 commands extra without them.

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

#222

Earlier quoted context omitted.

This is what I came to the comment section to say... You absolutely can pin dependencies.... da fudge? Sounds like this guy needs to finish learning Python before he learns something else. From what you suggested, to containerizing things with something like Docker, there are ways to make Python more easily distributable.

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.

You just pin the sub-dependency. This is builtin functionality for all the python environment managers.

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

#223
post #172

Earlier quoted context omitted.

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…

>But Python has a decent and a reproducible way of installing packages. Reading the comment thread it's not immediately clear what the answer is - it seems implied that the proper way is using Poetry, is that the case?

To me, yes. Poetry for me has been fairly straightforward, in anything I needed to do (dependency management, package publishing, etc).

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

#224

Earlier quoted context omitted.

Now try installing tensorflow. Treat yourself to ice cream if you get it to install without having to reinstall Linux and without borking the active project you're on.

And unless things have gotten a lot better in the 2 years since I last did `pip install numpy` on ARM, prepare for a very long wait because you'll be building it from source.

Sometimes if you don’t install wheel, it will also automatically fall back to source build. Very sweet.

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

#225

Earlier quoted context omitted.

It's a hassle to do this correctly and upgrade the dependencies. Use poetry.

pip freeze > requirements.txt

That only generates a lock file. When you want to upgrade some of your dependencies and recalculate the correct versions, it doesn't help.

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

#226

Earlier quoted context omitted.

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…

Its not a mess, people just make it a mess because of the lack of understanding around it, and getting lazy with using a combination of pip install, apt install, and whatever else. Also, the problem is compounded by people using Mac to develop, which have a different way of handling system wide python installs from brew, and then trying to port that to Linux.

One could argue that if you need a lot of understanding it is a mess.

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

#227
post #178

Earlier quoted context omitted.

It's a hassle to do this correctly and upgrade the dependencies. Use poetry.

Someone else already responded. It's a one-line command. I never could get poetry to work right; it's configs are sort of messy. pip freeze > requirements is built in. The only thing it doesn't pin is the python version itself.

As explained elsewhere in this thread, the one line command only generates a lock file. This doesn't manage the dependencies so if you want to upgrade cool-lib and recalculate all the transient dependencies so they fit with the rest of your libraries, you cannot afaik.

Bad non-solutions being built in are a bad thing.

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

#228
post #5

I hated the "damnable use requirement" (the error you get on unused imports) for years, but I've been keeping a count of how many bugs they've caught (I was surprised the first time this happened) and I'm up to 3-4 now. What people who code in Go seriously do is just hook `goimports` up to their editor, and then never think about this again.

How is this better than downgrading the error into a warning? You'd be able to build but would still know something was wrong-ish. Certainly a warning would be sufficient to chase down any bugs, and is very freeing compared to an error.

Knowingly shipping code that generates warnings during build is anti-social. It usually isn't that much work to fix a warning as you are writing the code and you encounter the warning the first time. It becomes much more expensive to fix warnings later because you do not have the mental context you had when you wrote the code.

But some people behave like that. They think it is someone else's job to chase down bugs in their code after they have knowingly submitted code with defects rather than deal with it immediately.

Classifying something as an error rather than a warning makes zero difference to programmers who take care not to knowingly ship defects. It only makes a difference to people who were going to ignore it and let someone else take up their slack. And to be frank: why on earth would you want to accomodate them?

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

#229

I don't think Python packaging is as bad as people make out (if packages only stick to the basic features of Python!) A far bigger issue I see is despite Python supposedly being 'cross-platform': the language introduces so many small, backwards-compatibility breaking changes that you really need to use the most up to date interpreter you can. For instance: there is now a really cool operator that lets you do expressi…

There's what people think and then there is observed reality. Observed reality informs us that this is a big problem with Python, so we'll just have to accept that. What people could do isn't the issue - what people do is. Also, you don't fix a problem by adding complexity and unpredictability. Again, as reality informs us, this hasn't worked for Python. It is still a mess.

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

#230

Earlier quoted context omitted.

pip freeze > requirements.txt

That only generates a lock file. When you want to upgrade some of your dependencies and recalculate the correct versions, it doesn't help.

How's that an issue? Here's an example of what happens: https://gist.github.com/robertlagrant/23489d8970ef6b49960307...
Post reply on HN