This, of course, only works on little-endian machines. On big-endian machines, c has to be bytereversed.
Interesting advantage of little endian!
This, of course, only works on little-endian machines. On big-endian machines, c has to be bytereversed.
Interesting advantage of little endian!
I’d switch course to RISC-V
And give up their only advantage? That would be insane. RISC-V isn't quite mature enough to replace x86 anyway.
I dunno maybe once a week or so? We don't actually have a system that detects if your pip install
is out of sync with pyproject.toml
yet so I run it occasionally just to make sure.
And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want.
It requires you to sign into a Microsoft account (which I assume most non-nerds do, given how hard they make it to avoid) and have hardware that supports it... But yes Windows enables full disk encryption by default now.
When you first sign in or set up a device with a Microsoft account, or work or school account, Device Encryption is turned on and a recovery key is attached to that account.
Oo hello. Didn't know that's what you were doing these days! Hope it goes well, though I'd be nervous about a realistic business plan.
Anyway, yeah bit too late for Python.
Well this isn't a standard library either then. But seeing as it is literally called that I'd say your unusually restrictive definition is nonsense.
I'm not sure hardware-based full disk encryption counts as a "highly specialized requirement". It's enabled by default on Android, iOS, Mac and even Windows usually. It's a basic requirement for businesses.
they wouldn’t have made a different tool altogether if it was really a 1:1 replacement
Why not? It's 10x faster.
I think it might have some other new features but you don't need to use those.
i doubt one person on the team could be using uv while everyone else sticks to pip
This is exactly what we do at work. There's no way I could convince everyone to switch to uv
so I just switch between them based on an environment variable.
It even supports random stuff like pip install --config-settings editable_mode=compat --editable foo
which is required for static tooling to work (e.g. Pyright).
you generally use a SAT solver for dependency resolution (unless you don’t care for correctness)
Actually Go's dependency system is specifically designed to avoid the need for global constraint solvers. Go has the most modern and elegant dependency versioning system that I'm aware of. Python was designed before people realised that it's dependency style was a mistake.
uv
is a drop-in replacement for pip
. There's no extra standard. It's pareto better. Honestly the Python community would do the world a favour if the deprecated pip and adopted uv as the official tool, but you can guess how likely that is...
uv
is fantastic. I would highly recommend it. I've used it in a quite complex environment, with no issues (quite an achievement!) and it's about 10x faster than pip.
I mean... I guess it's not surprising given uv
is written in Rust and pip is written in Python, but even so given pip is surely IO bound I was expecting something like 4x improvement. 10x is impressive.
Yeah...