> Man, it's easy to be fast when you're wrong. But of course it is fast because Rust not because it just skips the hard parts of dependency constraint solving and hopes people don't notice.
I think you're misunderstanding why we do this: it's a security feature. pip's design is inherently vulnerable to dependency confusion attacks, since packages of the same name across indexes are considered equally trusted by pip. You can look up the torchtriton attack to learn more.
> Stuff like this sense unlikely to contribute to overall runtime, but it does decrease flexibility.
I think you're misinformed. We support all of these features: system- and per-user configuration files, environment variables, etc. We just don't read _pip's_ configuration file, which is intended for pip, not uv.
I'm not super familiar with Bundler's architecture but I think the most impactful thing would be adopting uv's cache design, which is a big part of what makes uv so fast and should be replicable in other languages and ecosystems.
> Ignoring requires-python upper bounds. When a package says it requires python<4.0, uv ignores the upper bound and only checks the lower. This reduces resolver backtracking dramatically since upper bounds are almost always wrong.
I don't think that ignoring upper bounds has a significant impact on uv's performance. We do this for a totally different reason, which is that it leads to better solves. For example, if you say your project requires Python 3.8 or later, but some dependency said it works for ">=3.8,<4", then suddenly your project isn't installable on Python 4, and you'd be implicitly required to put a "<4" bound on your own project. uv solves for all of your supported Python versions, not a single version, so discounting the upper bounds doesn't actually save us any time in the solve.
If there's anything else accompanying the error, do you mind filing an issue? I've been using the ty extension with Cursor for weeks and am having trouble reproducing right now.
We actually do want ty to be a first-class LSP (i.e., a complete alternative to Pylance and others), and it already supports nearly all of the features you'd expect. I use it as my primary LSP today in lieu of Pylance!
The PEP includes the ability to enable (or disable) lazy imports globally via a command-line flag or environment variable, in addition to the import syntax.
Lazy imports have been proposed before, and were rejected most recently back in 2022: https://discuss.python.org/t/pep-690-lazy-imports-again/1966.... If I recall correctly, lazy imports are a feature supported in Cinder, Meta's version of CPython, and the PEP was driven by folks that worked on Cinder. Last time, a lot of the discussion centered around questions like: Should this be opt-in or opt-out? At what level? Should it be a build-flag for CPython itself? Etc. The linked post suggests that the Steering Council ultimately rejected it because of the complexity it would introduce to have two divergent "modes" of importing.
I hope this proposal succeeds. I would love to use this feature.
We ignore upper bounds because it leads to a better solve. You can read my comment here: https://news.ycombinator.com/item?id=46464453. There's significant discussion about this, e.g., here: https://discuss.python.org/t/requires-python-upper-limits/12....
> Ambiguity detection is important.
I think you're misunderstanding why we do this: it's a security feature. pip's design is inherently vulnerable to dependency confusion attacks, since packages of the same name across indexes are considered equally trusted by pip. You can look up the torchtriton attack to learn more.
> Stuff like this sense unlikely to contribute to overall runtime, but it does decrease flexibility.
I think you're misinformed. We support all of these features: system- and per-user configuration files, environment variables, etc. We just don't read _pip's_ configuration file, which is intended for pip, not uv.