- Async and Django don't mix well and I honestly see the whole Django Async as wasted resources, all those "a" prefixed functions etc.
To be honest, I never liked the way async is done in python at all.
However, I love Django and Python in general. When I need "async" in a http cycle flow, I use celery and run it in background.
If client side needs to be updated about the state of the background task, the best is to send the data to a websocket channel known to the client side. Either it's Chat response with LLM or importing a huge CSV file.
Simple rule for me is, "don't waste HTTP time, process quick and return quick".
- Just an update for whoever ends up on this comment.
This feature works as long as your venv that uv creates and the uv cache (in user home directory, or anywhere else that is configured to keep the cache folder) are both on the same filesystem.
The drive where the venv was created was NTFS and the user home directory where uv cache exists was ext4 file system.
Therefore the caching didn't work and a warning was shown by uv hinting to the problem.
- I use golang, rust and c++ here and there, but majority of my time is spent working in Python projects. I'm not alien to the concept of speed and performance, especially the tooling around them.
While I like the idea of pip or uv to be insanely fast, I still don't see it revolutionize my development experience.
Installing and uninstalling package is not something I do every 1 to 10 minutes. It doesn't save me any much time. Also, activating a venv is once a session in terminal and sometime a week goes by without ever activating a venv, because the IDE does that automatically on whatever I do.
That's why, personally for me it really doesn't change much.
Where I like things being fast in my development time is pre-commit and linting, where ruff shines. Which that I also don't use, even though I work on a small-medium 600k LoC project, I only pass the changed files to isort, flake8 and black and it's all done in less than 5 seconds.
To me, the only advantage of uv is being fast, which is something I haven't been bothered with so far, where 99% of things happen in less than 1 or max couple of seconds.
- Ooooh that's a neat one. I really like the hard links.
On my machine, there are like 100s of not thousands of venvs.
I simply have all of them under ~/.python_venvs/<project_name>/
Does that mean, no matter how many projects I install pytorch and tensoflow and huggingface and all the heavy machinery, they'll be counted only once as long as they're unique?
If that's the case, then I can leave my habit of pip and move to uv.
This is something that always bugged my mind about virtual environments in almost all the package managers.
- I seriously still don't know why I should use "uv". I just create my .venv and pip install.
Rarely I'd need a different version of python, in case I do, either I let the IDE to take care of it or just do pyenv.
I know there's the argument of being fast with uv, but most of the time, the actual downloading is the slowest part.
I'm not sure how big a project should be, before I feel pip is slow for me.
Currently, I have a project with around 50 direct dependencies and everything is installed in less than a min with a fresh venv and without pip cache.
Also, if I ever, ever needed lock files stuff, I use pipx. Never needed the hash of the packages the way it's done in package-lock.json.
Maybe, I'm just not the target audience of uv.
- Me neither.
Introducing new keyword has become a recent thing in Python.
Seems Python has a deep scare since Python2 to Python3 time and is scared to do anything that causes such drama again.
For me, the worst of all is "async". If 2to3 didn't cause much division, the async definitely divided Python libraries in 2. Sync and Async.
Maybe if they want backward compatible solution, this can be done by some compile or runtime flag like they did with free threading no-gil.
- I wish all imports were lazy by default.
I know/heard there are "some" (which I haven't seen by the way) libraries that depend on import side effects, but the advantage is much bigger.
First of all, the circular import problem will go away, especially on type hints. Although there was a PEP or recent addition to make the annotation not not cause such issue.
Second and most important of all, is the launch time of Python applications. A CLI that uses many different parts of the app has to wait for all the imports to be done.
The second point becomes a lot painful when you have a large application, like a Django project where the auto reload becomes several seconds. Not only auto reload crawls, the testing cycle is slow as well. Every time you want to run test command, it has to wait several seconds. Painful.
So far the solution has been to do the lazy import by importing inside the methods where it's required. That is something, I never got to like to be honest.
Maybe it will be fixed in Python 4, where the JIT uses the type hints as well /s
- Almost 2 decades of working with python.
I create a venv. Pip install and keep my direct deps in requirements.txt
That's it. Never understood all these python dependency management problems dramas.
Recently, I started using pyproject.toml as well which makes the whole thing more compact.
I make lots of python packages too. Either I go setup.py or sometimes I like to use flit for no specific reason.
I haven't ever felt the need for something like uv. I'm good with pip.
- > For a long time I didn't realize why people were so down on ORMs until I tried using a non-django ORM, it really does set the bar.
This. Very much this.
I have given up on one finding such. The closest and nicest one that comes to mind is SQLAlchemy. The rest of languages or frameworks have indeed nothing compared to Django ORM and SQLAlchemy. It's not even fair to compare them.
- Yes. Migrations are checked into the source control. They're still the source of truth of the database changes.
Regarding read only models pointing to a tabel. It'd possible to use proxy models or even non managed models where with some mix of Managers it can provide what you're looking for.
For getting a subset of fields from a database tabel, Django provides ".only()" on the QuerySet which you can use to list all the fields explicitly and only them will be retrieved. It can even span to foreign field relations as well.
Diango ORM is indeed powerful and vrry flexible once you learn it. A novice developer can use it quickly and won't get in the way. An advanced developer can do very complex sfuff with it without touching any raw sql. Still, it's possible to write custom sql commands directly.
- This is an English language and of course majority westerners.
You say something against the mainstream media or US hegemony, you'll b labeled as Basiji or "iranian regime supporter" or "on Putin payroll".
Not a place for thinking even epsilon out of tunneled vision made by westerners propaganda machine.
After all, majority are the ones that gonna rewrite their project in different language or stack because "the landing page said so"
- Unicode errors were one the most painful and annoying issues I had. Regardless of working with xml files, parsing text or just dealing with anything text related. When upgrading to Python 3, they just vanished.
Anti ORM people probably don't know what ORM is or confused about their usage and benefit they bring.
Once you're dealing with several tables and relations and lots of aggregation and annotations, raw sql is the one way ticket to insanity.
By the way, thank you very much for making SQLAlchemy. You saved millions of hours of developer time and god knows how many SQL bugs have been prevented by using SQLAlchemy
I'm still using it with not a single issue (except when is messes up the iptables rules)
I still confidently, upgrade the docker across all the nodes, workers and managers and it just works. Not a single time that it caused an issue.