741–750 of 1001 posts
Earlier quoted context omitted.
You’re about to run an untrusted python script. The script can do whatever it wants to your system. Dependencies are the least of your worries.
The script is just a cat or vim away from audit. Its dependencies on the other hand…
Uv is so good. I'm a curmudgeon about adopting new tooling, and tried uv with a lot of skepticism, but it was just better in every way. And even if it wasn't so polished and reliable, the raw speed makes it hard to go back to any other tool. Uv combined with type hints reaching critical mass in the Python ecosystem, and how solid PyLance is in VSCode, feels so good it has made me consider investing in Python as my pr…
> But then I remember that Python is dog slow compared to other languages with comparable ergonomics and first-class support for static typing, and...idk it's a tough sell. Post like these aptly describe why companies are downsizing in lieu of AI assistants, and they are not wrong for doing so. Yes, Python is "slow". The thing is, compute is cheap these days and development time is expensive. $1000 per month is consi…
Uv is so good. I'm a curmudgeon about adopting new tooling, and tried uv with a lot of skepticism, but it was just better in every way. And even if it wasn't so polished and reliable, the raw speed makes it hard to go back to any other tool. Uv combined with type hints reaching critical mass in the Python ecosystem, and how solid PyLance is in VSCode, feels so good it has made me consider investing in Python as my pr…
> But then I remember that Python is dog slow compared to other languages with comparable ergonomics and first-class support for static typing, and...idk it's a tough sell. Case in point: uv itself is not written in Python. It's a Rust tool. It always amazes me when people work on an ecosystem for a language but then don't buy enough into that to actually use it to do the work. Avoidance of dogfooding is a big red fl…
Earlier quoted context omitted.
https://docs.astral.sh/uv/guides/integration/pytorch/#using-... does that fit the bill?
Not the OP but does this actually package CUDA and the CUDA toolchain itself or just the libraries around it? Can it work only with PyTorch or "any" other library? Conda packaging system and the registry is capable of understanding things like ABI and binary compatibility. It can resolve not only Python dependencies but the binary dependencies too. Think more like dnf, yum, apt but OS-agnostic including Windows. As f…
Earlier quoted context omitted.
You say this on a message board run by a VC about a programming language that is primarily developed by meta, google and co. uv is MIT licensed so if they rug pull, you can fork.
It's still annoying to fork and they will probably try to move it to their own pypi service so it won't be possible to do that.
The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see…
Uv is so good. I'm a curmudgeon about adopting new tooling, and tried uv with a lot of skepticism, but it was just better in every way. And even if it wasn't so polished and reliable, the raw speed makes it hard to go back to any other tool. Uv combined with type hints reaching critical mass in the Python ecosystem, and how solid PyLance is in VSCode, feels so good it has made me consider investing in Python as my pr…
> But then I remember that Python is dog slow compared to other languages with comparable ergonomics and first-class support for static typing, and...idk it's a tough sell. Case in point: uv itself is not written in Python. It's a Rust tool. It always amazes me when people work on an ecosystem for a language but then don't buy enough into that to actually use it to do the work. Avoidance of dogfooding is a big red fl…
The power of Python is that it's high level and very powerful and has a great community and ecosystem of tools/libraries. There's absolutely zero problem and totally a good thing if there are core libraries written in faster languages.
Earlier quoted context omitted.
This was always my issue with pip and venv: I don’t want a thing that hijacks my terminal and PATH, flips my world upside down and makes writing automated headless scripts and systemd services a huge pain. When I drop into a Node.js project, usually some things have changed, but I always know that if I need to, I can find all of my dependencies in my node_modules folder, and I can package up that folder and move it w…
For not having to call 'source ...' in a Dockerfile, if you use the python executable from the virtualenv directly, then it will be as if you've activated that virtualenv. This works because of the relative path to the pyenv.cfg file.
Earlier quoted context omitted.
https://docs.astral.sh/uv/guides/integration/pytorch/#using-... does that fit the bill?
Not the OP but does this actually package CUDA and the CUDA toolchain itself or just the libraries around it? Can it work only with PyTorch or "any" other library? Conda packaging system and the registry is capable of understanding things like ABI and binary compatibility. It can resolve not only Python dependencies but the binary dependencies too. Think more like dnf, yum, apt but OS-agnostic including Windows. As f…
Earlier quoted context omitted.
> But then I remember that Python is dog slow compared to other languages with comparable ergonomics and first-class support for static typing, and...idk it's a tough sell. Case in point: uv itself is not written in Python. It's a Rust tool. It always amazes me when people work on an ecosystem for a language but then don't buy enough into that to actually use it to do the work. Avoidance of dogfooding is a big red fl…
I understand the argument but the language used for uv (rust) and python don't have the same goal. Python aims to be simple, not particularly fast (though it is getting faster) I don't see a problem with that. Pick the language adapted to your problem. Python isn't aiming at solving every problem and that's okay.
Well, it wildly missed the mark there. Nothing about modern Python is simple. It's a very complex language hiding behind friendly syntax.