Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Modern Practices

stuartellis.name

Post reply on HN
Print view View original

31–40 of 56 posts

Re: Python Modern Practices

#31

Post by igorguerrero »

thomasahle wrote: post #16

> Use requirements.txt Files to Install Packages Into Environments Isn't this obsoleted by the previous section on using pyproject.toml?

As far as I know you're right, also using pyproject.toml generates platform independent dependency trees (I don't have experience with the tools he mentions but that's what poetry does), requirements.txt does not and must be generated on a server or carefully picking the crossplatform version of the packages.

Also kinda weird he says to not use pip, but requirements.txt are pip commands... And should be running with pip... Hmm I don't know about this article anymore.

Re: Python Modern Practices

#32

Post by justanotherbody »

saboot wrote: post #15
ctoth wrote: post #10

Sad to not see Attrs mentioned. Dataclasses are cool, I guess, but Attrs is seriously great.

attrs looks interesting, can it be used in workflows for processing GBs of data? I don't see any Cython compatibility or other Python to compiled code options. I typically just get by with numpy recarrays, but I'm old fashioned and looking for something more modern.

Attrs would not replace your record array. IIRC you can supply slots so it might be useful for converting raw data into your numpy types, but I suspect you'd find the overhead in function calls problematic

If you want easier than recarray and almost as fast I think you're in pandas-ville

Re: Python Modern Practices

#33

Post by alisonatwork »

SCUSKU wrote: post #3
jw887c wrote: post #2

>Avoid using Poetry for new projects. Poetry predates many standards for Python tooling. This means that it uses non-standard implementations of key features, such as the dependency resolver and configuration formats in pyproject.toml files. What? This is the first I've heard of this.

Was going to comment the same thing. Would love to hear the author expand further on why not use Poetry. I've found it to be pretty solid and continue to use Poetry + Pyenv for all my projects, but open to hearing the case for PDM or Hatch.

I've never worked on a team that uses Poetry, but in my current company another team uses it, and I haven't found it really as slick as I would have imagined, primarily because you need to create a venv and install poetry into that before you even get started, which by that point why not just pip install the rest anyway? For standalone applications it just seems like an unnecessary extra step. It doesn't even mandate a build lifecycle like Maven so what are you getting?

But that's not what soured me on Poetry. What soured me was recently I needed to create a release of one of their libraries with a Git commit in the local version identifier and... Poetry doesn't do that. There's an issue that was open on GitHub for years before they finally agreed to implement it, and since February the change is now merged to master, but despite several point releases since then, that change has not landed in any of them. When will we be able to get a local version part? Who knows!

This experience has really made me skeptical of Poetry being the One True Packaging Tool that fixes everything. As usual, it just fixes the things the devs want fixed and everything else is still janky or half implemented. From my perspective, if you're gonna deal with jank anyway, might as well just deal with the standard jank that comes as part of Python itself.

Re: Python Modern Practices

#34

Post by chao- »

mikepurvis wrote: post #29
jw887c wrote: post #2

>Avoid using Poetry for new projects. Poetry predates many standards for Python tooling. This means that it uses non-standard implementations of key features, such as the dependency resolver and configuration formats in pyproject.toml files. What? This is the first I've heard of this.

Agree, I'm a poetry person too. I feel like TFA might be getting ahead of itself on this point. Just because something was ratified as a "standard" doesn't immediately make everything prior irrelevant.

Agreed. Most of these are fairly uncontroversial. A few will probably be new to some, particularly because users of Python are heterogenous and people find themselves with years of experience on projects that never upgraded their language version, e.g. from 3.6, and don't know that they're missing.

A final few, even with the explanation given, feels like preference, such as the Poetry opinion. I suppose if I wrote a similar article, it would end up with a similar mix of obvious defaults and a few of my preferences.

It could also be because of different use cases? For example, writing a library for packaging, vs a deployed application, vs a personal projects' workbench. Or perhaps if you are collaborating with people who use Windows without WSL. I have heard tell that Poetry can sometimes trip over its own shoelaces on Windows. I have never experienced it myself, and don't personally care to support any projects involving Windows, but if I did I might have different preferences.

Re: Python Modern Practices

#35

Post by rat87 »

frankjr wrote: post #11

I'm surprised the post doesn't mention uv, which did quite well on HN a few months ago. Any experience? https://github.com/astral-sh/uv https://news.ycombinator.com/item?id=39387641

I'm surprised it doesn't mention rye. I now that technically the projects are combining and uv is eventually meant to eat rye but for now I think it offers higher level functionality that I'm unsure if uv provides. Like pinning /downloading different Python interpreters. Rye and uv both allow installing tools in custom venvs removing the need for pipx.

Re: Python Modern Practices

#36

Post by rat87 »

thomasahle wrote: post #16

> Use requirements.txt Files to Install Packages Into Environments Isn't this obsoleted by the previous section on using pyproject.toml?

uv and rye (which depends on uv) use pyproject.toml and spit out requirements.txt like files as lock files. They aren't platform independent but are easier to install in a docket container (just use pip inside the container). Not sure about hatch/pdm which they recommended. Some people use pip-compile which also converts toml files in requirements.txt files

Re: Python Modern Practices

#37

Post by rat87 »

SCUSKU wrote: post #3
jw887c wrote: post #2

>Avoid using Poetry for new projects. Poetry predates many standards for Python tooling. This means that it uses non-standard implementations of key features, such as the dependency resolver and configuration formats in pyproject.toml files. What? This is the first I've heard of this.

Was going to comment the same thing. Would love to hear the author expand further on why not use Poetry. I've found it to be pretty solid and continue to use Poetry + Pyenv for all my projects, but open to hearing the case for PDM or Hatch.

After struggling with the complexity of pyenv and slowness of poetry I'm really happy with rye.

It manages both python versions (which it downloads instead of compiling) and package versions. It's written in rust so it's faster and can replace pipx as well for installing global tools. (Some people will recommend uv which rye is slowly merging with buy uv is still missing some rye features, probably some time in the future you might want to switch).

Re: Python Modern Practices

#38

Post by skeledrew »

I've been using conda+poetry as my goto combo for years now and it's served me very well. Sure it's said poetry doesn't follow certain standards, but it just abstracts away so much that I don't see myself needing anything else really. If I want to share a non-poetry artifact, it's a simple `poetry build` to create a wheel.

I did come across a weird dependency confusion issue recently when I tried using it on a server setup with piku though, but haven't gotten around to find what exactly is happening.

Also don't think I'll ever give up on YAML for it's easy read+write, and I love the simplicity of fire for CLI things. And pathlib.Path().glob() for directory listing.

Re: Python Modern Practices

#40

Post by skeledrew »

helsinki wrote: post #4

I've not had any issues using mamba environments and vanilla pip. Not sure why I would need to change that? I have packages that thousands of people use, and others that help manage billions of dollars. I've managed to keep things simple without upgrading tooling. This article feels like it's suggesting flavor of the month technologies without explaining why the status quo is bad. Also, you can't really use virtualen…

I use conda exactly so I can manage non-Python stuff in envs.
Post reply on HN