> Man, it's easy to be fast when you're wrong.

There's never going to be a Python 4 so I don't think they are wrong. Even if lighting strikes thrice there's no way they could migrate people to Python 4 before uv could be updated to "fix" that.

> Ambiguity detection is important.

I'm not sure what you mean here. Pip doesn't detect any ambiguities. In fact Pip's behaviour is a gaping security hole that they've refused to fix, and as far as I know the only way to avoid it is to use `uv` (or register all of your internal company package names on PyPI which nobody wants to do).

> thus shifting the bytecode compilation burden to first startup after install

Which is a much better option.

There's never going to be a Python 4

There will, but called Pyku ...

> Pip doesn't detect any ambiguities. In fact Pip's behaviour is a gaping security hole that they've refused to fix, and as far as I know the only way to avoid it is to use `uv`

Agreed the current behavior is stupid, FWIW. I hope PEPs 708 and 752 get implemented soon. I'm just pointing out that there's an important qualitative difference between

1. we do the same job, but much faster; and

2. we decided your job is stupid and so don't do it, realizing speedups.

uv presents itself as #1 but is actually #2, and that's a shame.