tracnar's comments

On: I ported JustHTML from Python to JavaScript with Codex CLI and GPT-5.2 in hours

[tracnar]

If you're porting a library, you can use the original implementation as an 'oracle' for your tests. Which means you only need a way to write/generate inputs, then verify the output matches the original implementation.

It doesn't work for everything of course but it's a nice way to bug-for-bug compatible rewrites.

On: A “frozen” dictionary for Python

[tracnar]

Indeed, the Tcl implementation does this so e.g. `set d [dict] ; dict set d key value` can modify d in place instead of creating a copy (since everything is immutable).

On: We should all be using dependency cooldowns

[tracnar]

You could use this funky tool from oss-rebuild which proxies registries so they return the state they were at a past date: https://github.com/google/oss-rebuild/tree/main/cmd/timewarp

[hoistbypetard → tracnar]

That... looks like it would let me do this exactly the way I want to for npm and python. For my C++ stuff, it's all vendored and manual anyway.

I had not seen that tool. Thanks for pointing it out.

On: Ask HN: How would you set up a child’s first Linux computer?

[tracnar]

There's Hedy if you want to try a text based programming language for kids: https://www.hedy.org/

On: Nix Derivation Madness

[tracnar]

What actually happens if you remove read permissions on the /nix/store directory? Do things still work? I suppose I'll need to try!

[kevincox → tracnar]

https://github.com/NixOS/rfcs/blob/master/rfcs/0097-no-read-... is relevant.

[Ericson2314 → kevincox]

Oh hmm did we never implement this? We should. Both because it is a good idea, and because accepted RFCs should be implemented.

[kevincox → Ericson2314]

I'm not aware of it being done yet. But since the RFC is accepted it should be pretty straightforward.

On: Show HN: Modshim – A new alternative to monkey-patching in Python

[tracnar]

I wish a Python package manager would support patching dependencies, like e.g. Cargo allows: https://doc.rust-lang.org/cargo/reference/overriding-depende...

It's much cleaner than monkey patching, and it will more likely detect if an update conflicts with your patching.

I've used it by packaging everything through nix, but that can be cumbersome.

On: JSON River – Parse JSON incrementally as it streams in

[tracnar]

Don't you need to wait for some kind of delimiter (like ",", "]", "}", newline, EOF) before parsing something else than a string?

[rictic → tracnar]

Only for numbers! Strings, objects, arrays, true, false, and null all have an unambiguous ending.

[stefs → rictic]

but you don't do this for strings either, as shown in the examples - partial strings are pushed even though they're not yet ended:

    {"name": "Ale"}

[rictic → stefs]

Oh this isn't about the public API, it's about the internal logic of the parser.

On: HRT's Python fork: Leveraging PEP 690 for faster imports

[tracnar]

While I see the usefulness of lazy imports, it always seemed a bit backward to me for the importer to ask for lazy import, especially if you make it an import keyword rather than a Python flag. Instead I'd expect the modules to declare (and maybe enforce) that they don't have side effects, that way you know they can be lazily imported, and it opens the door for more optimizations, like declaring the module immutable. That links to the performance barrier of Python due to its dynamic nature as discussed in https://news.ycombinator.com/item?id=44809387

Of course that doesn't solve the overhead of finding the modules, but that could be optimized without lazy import, for example by having a way to pre-compute the module locations at install time.

[instig007 → tracnar]

> it always seemed a bit backward to me for the importer to ask for lazy import, especially if you make it an import keyword rather than a Python flag

Exactly this. There must be zero side effects at module import time, not just for load times, but because the order of such effects is 1) undefined, 2) heavily dependent on a import protocol implementation, and 3) poses safety and security nightmares that Python devs don't seem to care much about until bad things happen at the most inconvenient time possible.

> Of course that doesn't solve the overhead of finding the modules, but that could be optimized without lazy import, for example by having a way to pre-compute the module locations at install time.

1) opt for https://docs.python.org/3/reference/import.html#replacing-th...

2) pre-compute everything in CI by using a solution from (1) and doing universal toplevel import of the entire Python monorepo (safe, given no side effects).

3) This step can be used to scan all toplevel definitions too, to gather extra code meta useful for various dynamic dispatch at runtime without complex lookups. See for example: https://docs.pylonsproject.org/projects/venusian/en/latest/i...

3) put the result of (2) and (3) as a machine-readable dump, read by (1) as the alternative optimised loading branch.

4) deploy (3) together with your program.

[tracnar → instig007]

For optimizing the module finding, using a custom import hook was indeed what I had in mind!

On: The future is not self-hosted

[tracnar]

I've always thought it would be great for the government to provide a free domain name for every citizen. There's really not much you can do without DNS.

On: Implementing Logic Programming

[tracnar]

For logic in Python this project looks pretty neat, it encodes facts as typed objects and rules as functions, then allows you to run the model using a solver like soufflé: https://py-typedlogic.github.io/

I haven't found an excuse to really use it though!