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.
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.
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.
Yes. For the project I work on pip install takes about 60 seconds and replacing it with uv reduces that to about 7 seconds. That’s a very significant improvement. Much less annoying interactively and in CI we do this multiple times so it saves a significant chunk of time.
Not really because RefCell has performance implications and also adds noise to the code.
But I would not be a fan of implicitely allowing multiple mutable borrows without any clue for that in the code.
Nobody is suggesting breaking Rust’s multiple mutable borrow restriction. The macro solution simply doesn’t do that, and the “make the borrow checker smarter” solution just releases the mutable borrows when they aren’t being used so they don’t overlap.
The benefits are that you don’t have to pass out and similar captured variables into the closures/functions.
Yeah that’s pretty unreadable IMO. I think your second link isn’t what you intended?
I dunno, does it even need a new feature? Kind of feels like Rust should be able to figure it out as long as the lambdas aren’t moved/stored/etc?
Sorry that example was a bit too limited to demonstrate the problem actually. Add a second lambda and you hit the issue:
Still totally fine from a safety point of view, but the borrow checker can’t figure that out.
I disagree. It’s a sign your code isn’t structured in a way that the borrow checker understands, but that is a subset of well-structured code.
In other words, if your code nicely fits with the borrow checker then it’s likely well structured, but the inverse is not necessarily true.
One thing I always run into is using lambdas to reduce code duplication within a function. For example writing a RLE encoder:
fn encode(data: &[u8]) -> Vec<u8> {
let mut out = Vec::new();
let mut repeat_count = 0;
let mut output_repeat = || {
out.push(... repeat_count ...);
};
for d in data {
output_repeat();
...
}
output_repeat();
out
}
This is a pretty common pattern where you have a “pending” thing and need to resolve it in the loop and after the loop. In C++ you can easily use lambdas like this to avoid duplication.
Doesn’t work in Rust though even though it’s totally fine, because the borrow checker isn’t smart enough. Instead I always end up defining inline functions and explicitly passing the parameters (&mut out) in. It’s much less ergonomic.
(If anyone has any better ideas how to solve this problem btw I’m all ears - I’ve never heard anyone even mention this issue in Rust.)
Thanks for finally being explicit about the kind of person you are.
As if wokeness isn’t a thing 🙄
You seem to be giving a lot more leeway to interpretations of Peters’ words than my comparison. Odd.
It doesn’t require any leeway. It’s a totally mainstream opinion supported by actual research. It’s only in woke CoC teams that comments like that are objectionable.
he’s also dismissing that it’s worthwhile to try and have an environment free from sexual harassment.
Complete misunderstanding of his comment. Read it again.
Gracefully accepting constructive criticism.
Lol the irony is overpowering.
If you “made light of sexual harassment training” at your job like this you would be fired?
And I lost count of how many times an executive at a startup I’ve worked for was charged with sexual harassment. The outcome was always the same: nothing actually happened to them, but the entire company was sentenced to days of “sexual harassment prevention” training, as part of the deal the bigwig cut to get off easy. By now I must be one of the most highly trained people on Earth in that specialty :wink:.
Jesus you should leave now! That’s not ok. (At least in countries with proper labour laws; I guess in America they can fire you for anything.)
I mean I wouldn’t advise writing that on your company Slack, but nowhere I have ever worked would fire you for it.
In any case the Python community isn’t a company & as far as I understand it Peters isn’t getting paid.
So either you agree with what it’s called or you’re “disruptive” and should be banned? Hmm.
I read a load of his comments and they seem quite reasonable. A million miles from ban-worthy.
Those sensors are pure trash. Use SHT-75 or SHT-85 if you actually care about getting a real value. More expensive though.
Is that even desirable? There are other runtimes for specific things, e.g. for embedded, WASM, Fuchsia, etc. Doesn’t seem like there’s a one-size-fits-all runtime.
I guess the proper answer is some kind of minimum standard async interface, but presumably there’s a reason they haven’t done that.
I dunno really, I’ve avoided async Rust as much as possible due to the number of footguns it has.
Interesting advantage of little endian!