Alir3z4
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.
No wonder they made iPhone pocket now.
They should make tshirts for their laptops as well.
The ridiculous part is, people will buy this.
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".
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.
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.
I noticed the comment from andy99 got several downvotes (became grey) and mine here also immediately got some.
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.
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.
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 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
TBH, I've seen tutorials or even some companies simply do `pip freeze > requirements.txt` :shrug: which is a mess.
`pyproject.toml` let's you set the min python version. If not met, it won't install.
Regardless, majority of the times, deployment is done via Docker.
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.
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.
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.
and first in line advocate to sanction Iran even in time of covid.
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"
Has been said for the last 44 years.
Python without its crazy amount of extensions in c-api won't survive.
Probably works for the company behind it.
I can explain the reason for all of them, but particularly "Service Layer" is something I don't see any fit in the realm of Django. The service layer doesn't go well with Django, especially the way it has been described in this style guide.
If I'm building an API endpoint, why would I want to implement the validations and business logic in some other class/function? Why can't that be done in the serializers? why not lock the database models by properly Meta.constraints or permission classes etc..?
This shows DRF serializers are being built as subclass inside the view class. Such an annoying take to me. Why? Why specifically have to have the Serializers, Paginators classes, and all the stuff indented into the API view class?
DRF ModelSerializers are automatically built around the validation definition of DB.models.Model, using the service layer means you lose all of that. The same is true for Django Forms or Django Admin or anything in Django. Django starts from models and ends with models.
Working on small to mid-size (_let alone large Django projects_), the worst I can do is to follow such guidelines. Swimming against the river stream.
The settings/* structure is a mess in itself as well. Every project doing 1 setting per environment ended up having tens of them to support different ends and lots of confusion in what is doing what.
Service Layer is not a fit for Django and it will never be (_at least the way Django is atm_).
Do yourself a favor and don't follow such guidelines, just because they have thousands stars doesn't make them valid.
Looking at code samples, it doesn't look like Django or how Django projects look like.
Django is simple, Views, Serializers, Models, Forms and that's it. All of them work in harmony and trying to cut them through with such patterns will cause you to lose many benefits of the framework.
edit: typos
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
Sure. Apparently I should also believe Iran has WMD and NATO should attack it. It's coming from a unnamed sources.
> In early-November, an unnamed source at Tehran's Imam Khomeini Airport told Kayhan-London
> Citing an unnamed Iranian source,
> There are also unconfirmed reports that officials are transferring their assets to friendly countries
Basically, "source? trust me bro!"