They do, but the US can still force them to hand over data that's in EU. (This was confirmed by Microsoft France officials.)

At least in Belgium it's quite common for a lot of students to fail the first year (partly due to the difficulty, partly due to partying instead of studying). But it's not like it's really free, the tuition is cheap but the accomodation is expensive. I also don't think it's particularly difficult on purpose to filter out students, it's just that it's not overly expensive and a lot of people are unsure about what to study.

According to [1] at one Belgian university 61.8% of students reached a milestone within 2 years (with 41.4% reaching it within 1 year)

That's quite a high non-completion rate - but it's nowhere near 99%.

[1] https://nieuws.kuleuven.be/en/content/2023/42-6-of-new-stude...

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.

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).

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

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.

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

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

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

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

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

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.

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

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

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"}

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

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.

> 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.

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