henryiii

il y a 2 ansdiscuss

Or update things that are dated now. I’ve been mostly keeping the max version up to date but haven’t bumped the min version yet. I’d like to make it 3.11 or 3.15 in the near future.

henryiii

il y a 2 ansdiscuss

Feel free to make a MR, that sounds like a good tip. :)

henryiii

il y a 4 ansdiscuss

From what I understand, Hatch fixes a core failure of Poetry & PDM: if you have a tool that is not a library (say Black), it should not be able to collide with another tool you are using (say TensorFlow). For a while, black and TensorFlow could not be installed in the same environment due to bad upper caps (In Python, never upper cap without proof it fails or will fail, see https://iscinumpy.dev/post/bound-version-constraints/) - and that's fine, TensorFlow and Black don't use each other. But Poetry/PDM will fail (and this is why Poetry's solve times can be insane). Hypermodern-python still tries to jam everything into a massive Poetry dev environment, which can create multi-hour solves if you add things like TensorFlow.

Today we've been "fixing" this by using nox or tox, and avoiding adding everything into a big "dev" environment. But the draw of Poetry/PDM was supposed to be "A single tool". Very excited to see where this goes! I've already enjoyed hatchling, which can be used on it's own with other systems. :) (Except Poetry, which doesn't play well with standards or anyone else).

henryiii

il y a 4 ansdiscuss

Poetry does several things by default that are bad for libraries - see https://iscinumpy.dev/post/poetry-versions/ for some details.

henryiii

il y a 5 ansdiscuss

That’s never been true for packages. Just because someone else did it doesn’t mean you can’t do it better. The goal in the last few years has been to make it possible for anyone to write a build system or tooling, just like any other library in Python. Otherwise there is no innovation.

henryiii

il y a 6 ansdiscuss

I'm excited, but it seems like setting names by default is very odd. Quite a bit of the PEP is dedicated to the odd situations created by "case x" actually setting x rather than reading x ("case .x" would read x). Wouldn't this be a natural place for := ? So you would do:

  case x := _

to match and assign to x. "_" would always be the matcher. You always have access to the original item that the match was made on, so pulling out the matched items is often not needed, AFAICT. This would be explicit, and not too surprising. Then the whole dotted names part can be dropped - it works like normal Python at that point.

The PEP already suggests this for capturing parts of the match, why not just use it for all saved matches? It's more verbose, but consistent, with fewer caveats, and not always needed.

Disclaimer: My languages don't happen to include one with good pattern matching, so I'm not strongly familiar with it.

Submissions

Hist 2.5 and boost-histogram 1.2 released

comments