News for hackers. Stuff that matters.

henryiii

Re:An Introduction to Modern CMake on Friday March 22, 2024 @06:04PM (#39795343)
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.
Re:An Introduction to Modern CMake on Friday March 22, 2024 @06:01PM (#39795327)
Feel free to make a MR, that sounds like a good tip. :)
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).

Poetry does several things by default that are bad for libraries - see https://iscinumpy.dev/post/poetry-versions/ for some details.
Re:You shouldn't invoke setup.py directly on Tuesday October 19, 2021 @06:31PM (#28924583)
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.

Hist 2.5 and boost-histogram 1.2 released

I'd like to announce the release of Hist 2.5 & boost-histogram 1.2, the powerful histogramming libraries for Python. I don't think I've posted about them here before, so quickly, boost-histogram is a pybind11 wrapper for the Boost.Histogram C++ library, written in close collaboration with the Boost library author, which gives Python users object-oriented histograms with incredible...

( Read More... | no comments | 2 points | on HN )
Re:PEP 622 – Structural Pattern Matching on Thursday June 25, 2020 @02:38PM (#23643978)
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.

Re:Python vs. NumPy vs. Nim on Tuesday May 15, 2018 @04:42PM (#17077699)
I've added several others, including C++, as well as a faster numpy implementation (avoiding mixing double and float): https://github.com/henryiii/framework_compare/tree/master/li...