Hacker News: wrmsr

New comment by wrmsr in "PEP 810 – Explicit lazy imports"

wrmsr — Fri, 03 Oct 2025 19:23:52 +0000

If anyone's interested I've implemented a fairly user friendly lazy import mechanism in the form of context managers (auto_proxy_import/init) at https://pypi.org/project/lazyimp/ that I use fairly heavily. Syntactically it's just wrapping otherwise unmodified import statements in a with block, so tools 'just work' and it can be easily disabled or told to import eagerly for debugging. It's powered primarily by swapping out the frame's f_builtins in a cext (as it needs more power than importlib hooks provide), but has a lame attempt at a threadsafe pure python version, and a super dumb global hook version.

I was skeptical and cautious with it at first but I've since moved large chunks of my codebase to it - it's caused surprisingly few problems (honestly none besides forgetting to handle some import-time registration in some modules) and the speed boost is addictive.

New comment by wrmsr in "What’s New in Python 3.10"

wrmsr — Wed, 17 Feb 2021 04:32:48 +0000

If you're building anything past a hello world c ext you're already off the path of shit like poetry, in which case AIUI we're basically on our own as we've always been lol, for better and worse.

Again I don't think setup.py is going away. Given that distsetuputiltools is a jenga tower of decades old monkeypatches documentation is understandably sparse, but they're at least passively open about how gross it is to work within. Subclassing or otherwise manually overriding the behavior of distutils classes like build_* is just how stuff is done at this level and I don't expect that to change, beyond just updating your stuff to subclass or hook direct setuptools equivs of existing distutils classes. distutils is already vendored by setuptools anyway, so you're already not really hitting 'distutils' as much as 'setuptools._distutils' aliased to distutils upon importing setuptools (and specifically importing it first ( https://github.com/pypa/setuptools/blob/c121d289da5d19cf6df2... )), so all this really does is collapse a level of hack.

As long as py2 remains supported I expect whatever changes happen here to be py2 compat, but I do expect new setuptools to break compat with old setup.py's. But setup.py being what it is it wouldn't be out of character to make your setup.py manually support both old pre-distutils-removal setuptools and new post-distutils-removal setuptools, but that's just how setup.py maintenance goes lol.

ed: ok well not so much py2 being 'supported' as 'no showstopping incompatibilities for anyone still straddling that ever widening gap' :)

New comment by wrmsr in "What’s New in Python 3.10"

wrmsr — Tue, 16 Feb 2021 23:48:59 +0000

AIUI, as the official way setuptools is used is a setup.py calling setuptools.setup(), doing this will remain supported in perpetuity and will really still be powering everything under the hood, it's just no longer what people are told to do when they ask 'how do I make a new python library?' - newcomers and people with simple requirements will be directed to poetry or whatever and avoid that whole mess. For obvious historical reasons python's pretty averse to large breaking changes, and its support for all kinds of weird native interops and obscure platforms is one of its major assets (but also why setuptools is such a mess), so that's almost certainly not going anywhere, even if it's now kept even further back in the shadows. Regarding pyproject.toml if you already have a setup.py doing what you need then it's really only for specifying suported python versions and setup_requires (solving the problem of your setup.py itself needing Cython/wheel/etc).

New comment by wrmsr in "Why Wasn't Ruby 3 Faster?"

wrmsr — Thu, 11 Feb 2021 03:56:16 +0000

Significant but as it's freethreaded you only run one large process. That alone allows for all kinds of additional optimizations that would be pointless with a lot of little singlethreaded processes in which sharing anything mutable between them has massive overhead.

New comment by wrmsr in "Moving from Macbook to Linux"

wrmsr — Sat, 21 Nov 2020 03:27:15 +0000

Past some critical mass local dev indeed simply doesn't work, but the majority of codebases aren't ~that~ large. And until that point I feel there's an analogy between having a light laptop and remotely doing your heavy lifting with the whole working remote thing in general. In theory, on paper, and assuming reliable decent internet connectivity, with a little elbow grease there should be no discernable difference between thin client remote dev and an in-your-lap xeon, just like with high quality low latency video teleconferencing with a team that knows how to do it there should be nothing lost with physical distance. In practice though the overhead of doing any little thing, no matter how small the overhead may be optimized down to, is still real. Non-verbal communication is lost on zoom and the distance between you and your real UI grew by hundreds of miles and dozens of links, and the tradeoffs your environment makes when there's no such thing as a 'quick check' add up fast. But it's obviously not one dimensional, and there's probably irony in the weight shedding that offers you 20 hrs of battery life coming with a price tag of requiring reliable wifi to get any real work done.

New comment by wrmsr in "Python 3.9"

wrmsr — Tue, 20 Oct 2020 14:24:53 +0000

I'm a fellow fan of antlr but it's not really an option for the base interpreter. They're (rightfully) very stingy about deps. cpython supports a wide range of platforms and has its own very permissive license - it's a pretty self-contained codebase and they prefer to keep it that way.

New comment by wrmsr in "PEP 638 – Syntactic Macros"

wrmsr — Thu, 15 Oct 2020 01:37:49 +0000

The whole point of python is to eschew 'magic' in favor of dumb explicitness, and this is about as big of a conflict as you can get to that. Python lacks statement lambdas not because they've never considered the possibility but explicitly because "if it's that important it deserves a name (as an inner function)". Type annotations work so well in python as compared to ruby or clojure exactly because of this philosophy. The PEP seems to make no mention of things like reproducibility, IO in macro expansion, static analysis like in mypy, or any of the other realities of things like this. If macro expansion is limited to something carefully statically interpretable like constexpr then I'm cautiously receptive to it, OR as it positions itself to be 'for experimenting with language features' and that's genuine then I'd be fine with it if it's only enabled in debug builds, but in lieu of those the instant it's released generally it's a python 4 flag day.

New comment by wrmsr in "Python Enhancement Proposal 638 – Syntactic Macros"

wrmsr — Sat, 26 Sep 2020 21:11:22 +0000

> You could use this to do little stunts like adding an "unless x:" statement equivalent to "if not x:"

You say that like it's a good thing. Python is a language empowered by its constraints. You have indeed always been able to pull stunts like this but it's strongly frowned upon - python is not ruby, lambdas intentionally do not have statements, and terseness is not a virtue.

New comment by wrmsr in "Fastcore: A library that extends Python with new features"

wrmsr — Sat, 05 Sep 2020 16:29:03 +0000

As far as I can tell functools.partial has been implemented in C since it was added sixteen years ago ( https://github.com/python/cpython/commit/9c323f8de4910dfc0ba... ), and it's faster than lambda ( https://gist.github.com/wrmsr/1e13eda3ed78288679c010acbe6d2b... ). Regarding docstrings you can access the underlying function via the __wrapped__ attribute, and signature forwarding is too brittle and magical for stdlib.

New comment by wrmsr in "A New Chapter for PyPy"

wrmsr — Thu, 13 Aug 2020 16:42:52 +0000

> Built for Scientific Computing

I mean the thing's called 'numba' lol.

I always liken Pypy to HotSpot in that to this day the numerical performance of the latter isn't spectacular and nobody really cares - it's built to handle the harder job of making vast tangled codebases of non-numerical application code run fast, not just tight math loops which are already handled perfectly well by other more specialized tools.

New comment by wrmsr in "George Floyd Protest – police brutality videos on Twitter"

wrmsr — Mon, 15 Jun 2020 07:03:53 +0000

It actually exceeds non-police theft these days: https://www.washingtonpost.com/news/wonk/wp/2015/11/23/cops-... ( https://outline.com/UX7nfW ).

New comment by wrmsr in "Functional Programming in Python"

wrmsr — Fri, 29 May 2020 02:35:48 +0000

As a language purist this one is surprisingly well put together. Its impl suffers from legacy (py2 support in general, predating builtin dataclasses, staying in the shallow end of type annotations) but it really does what it does better enough than its host language to be worth giving attention to. Check it out.

New comment by wrmsr in "Subinterpreters for Python"

wrmsr — Thu, 14 May 2020 00:18:25 +0000

and greenlet, and stackless, and pypy's stm..

python's never really been about dogma. part of why its package management is such a mess is because it's been so successful at integrating with everything under the sun and still needs to support it all.

New comment by wrmsr in "Doing Python Configuration Right (2019)"

wrmsr — Mon, 27 Apr 2020 17:48:22 +0000

If your python files are not in a python package (do not have __init__.py in their directory) then they will be importing non-relatively and resolution depends on sys.path. If you have a multi-file python project in which your source files have inter-dependencies you should be structuring it as [nested] packages not as a directory of scripts that happen to try to talk to each other (and thus be doing 'from . import requests'). It's not that this is a 'way to avoid' a problem, it's just that this is the correct way to do this. I fully agree though that package management remains one of python's biggest pain points, made even worse by just how much bad and long-outdated information is out there, and by how 'easy' it is to just dump code into a .py and run it, not knowing just how wrong that is for anything but a temporary scratch file or a deliberately engineered self-contained single-file portable script like black.

Python doesn't treat 'paths on disk' as special language tokens, python chooses to handle certain tokens by possibly accessing files on disk. Classes in java (lacking 'modules') resolve to equally named files during compilation, as it goes in go, node, haskell, and pretty much everything I can think of with the sole exception of C/C++ preprocessor driven multi-file development (which is even more filesystem-coupled than the former as you literally type filenames).

New comment by wrmsr in "Doing Python Configuration Right (2019)"

wrmsr — Mon, 27 Apr 2020 17:30:44 +0000

As below node has the luxuries of both having been able to learn lessons from python and ruby ~and~ not being a victim of its own success of being already integrated with and a dependency of most major operating systems. (That said javascript the language definitely ~is~ a victim of its own success in browsers - there's probably some metaphorical parallel here..)

But the 'python version' problem (and really just any notion of a 'system python' in general) is still absolutely one of the bigger pain points of the ecosystem. I can say that for nix OS's pyenv ( https://github.com/pyenv/pyenv/ ) is a real godsend for this though. Pure-bash, no bootstrap problem, doesn't need to be 'installed' / can just be cloned and used, and has been able to reliably install any version of python I've needed into any of my relevant platforms in a well isolated ~/.pyenv/version/v3.x.y from which I can '~/.pyenv/versions/v3.x.y/bin/python -m venv .venv' in my project's dev bootstrap/Makefile. It's not part of my production-bound Dockerfiles which just base off of the official python images but it's invaluable for development and testing.

If you are going to use it I definitely recommend cloning it directly to ~/.pyenv rather than installing it via brew or somesuch as those tend to lag further behind the most up-to-date python versions than I'd like. And this is of course in no way a general solution to all of python's many packaging woes, and it'll probably never really be as simple as packages.json for many very valid if unfortunate reasons, but the 'python version' problem is at least pretty well handled by pyenv.

New comment by wrmsr in "Doing Python Configuration Right (2019)"

wrmsr — Mon, 27 Apr 2020 17:07:41 +0000

Name conflicts were basically fixed in 2003 with absolute/relative imports ( https://www.python.org/dev/peps/pep-0328/ ) - you don't ever have to include the name of your library in imports within your library using relative imports and via absolute imports they will never conflict with a base-level (site/system) package. Regarding hyphens and such in package names pretty much every language has restrictions on identifier names.

New comment by wrmsr in "Python 2.7.18, the last release of Python 2"

wrmsr — Mon, 20 Apr 2020 22:42:37 +0000

Imagine if it was the day of the Super Bowl, and you wanted to go out to a sports bar that was going to be airing the Super Bowl. So you go out and find a bar that says they're throwing a Super Bowl party, and go in and settle in, and when it comes time for kickoff you realize that the bar is actually airing the Super Bowl from 10 years ago. Like, it would have been fine if they had called the party a 'Super Bowl from 10 years ago' party, and for some reason there's this part of the bar that seems to be all on board with rewatching the same Super Bowl from 10 years ago every year and frankly seems confused why the rest of the bar is confused and angry about it (I mean it's still the Super Bowl right?).

New comment by wrmsr in "What are the main benefits of Elixir compared to Clojure?"

wrmsr — Mon, 23 Mar 2020 09:48:29 +0000

loom ( https://jdk.java.net/loom/ ) is well on its way :)

New comment by wrmsr in "Federal Reserve slashes interest rates to zero"

wrmsr — Mon, 16 Mar 2020 07:32:10 +0000

Curing polio wouldn't be fair to everyone who already died of polio.

New comment by wrmsr in "Ask HN: Was the Y2K crisis real?"

wrmsr — Fri, 13 Mar 2020 03:50:29 +0000

Was the cold war real?