141–150 of 209 posts
Earlier quoted context omitted.
> data__family__spouse__name__istartswith="oli" that's some syntax right there :)
Couldn't tell if you meant to say it was good or bad, but actually I found it to be crystal clear which is impressive for a complicated dataset.
Earlier quoted context omitted.
90% of the time I don't want it. Database, cache, etc, not really that bothered. Web requests take 100-300ms to complete, tying up a worker for 300ms isn't much of a problem. 10% of the time I'm calling an API that takes 3s and tying up a worker for 3s _might_ be a problem. Being able to not do that would be really handy sometimes. Not web servers, but I also do a lot of web scraping and Python is definitely the best…
Web requests taking over 100 ms is an absolute shame that slow languages like python are enabling.
As a point of comparison, Amazon's time to first byte for me is 270ms, with a 15ms round-trip time to their servers, so they're looking at about 255ms to serve a page.
To get significantly faster than this, a site must be engineered for speed from the ground up, and the productivity hit would be huge. We've got ~250k lines of Python, which would probably translate to ~750k lines of Go (which is fast, but not that fast), or probably >1m lines of C++. Engineers don't tend to produce that much more or less in terms of line count, so this would likely take ~4-6x the time to create (very rough ballpark). Plus, with a codebase so much larger there's a greater need for tooling support, maintenance becomes harder, more engineers are needed, etc.
When speed is the winning factor, like it sometimes is for a SaaS API that does something important in a hot code path (e.g. Algolia) then this is all worth it. When you're a consumer product where reacting to consumer demand is the most important thing, the speed difference really isn't worth it.
Pardon the rant, but I feel that the advantages don't outweigh the fact that with each release some of my stuff gets broken and I need to adjust. Django puts DeprecationWarnings basically everywhere and it's a hell to maintain projects that had been alive for a few years. God forbid you do anything with the interfaces they expose. The problem is only getting worse when you consider your dependencies, which in many ca…
A lot of the imports seem to move around (which is easy to fix, once you know where they now are), and some things have just vanished.
I know documentation is a nightmare to produce, but there must be a way to automatically produce it for either import relocations or deprecations so you can find things like this easily?
Async views have dropped, and that is genuinely exciting. It's taken a lot of work, and there's still a ways to go before Django is truly async native, but this is one of the big steps, and being able to do some concurrent IO on a few routes could be a huge saving for some projects that call out.
Otherwise a lot of stuff has to be done in event queues, to avoid blocking the main thread, and sometimes that means a bad UX when users take actions and aren't offered the guarantee that they are complete - in times where that might be the best option, were you not risking blocking thread.
Slightly OT: How does HN feel about the recent craze to make web python asynchronous? To me, the performance gains are dubious in many cases and the complexity overhead of handling cooperative multitasking just seems like a step back for a language like python.
Long term Python user: if I want to do something asynchronously I reach for Go or Elixir (unless it's just way more practical to do it right there in Python). Adding function colors [1] might have been a practical decision, but was IMHO a mistake. Why do I have to decide if my function is synchronous or not when I write it? I don't want to do that, I want to write only one function that can be called synchronously or…
I feel that sync and async functions are fundamentally different. In python coroutine is really just a function you can pause and while it might seem like it's the same thing as a normal function it's actually very different algorithmic-ally speaking as you can include a lot of low level optimizations which is really what async code is all about — getting rid of that IO waiting.
I love async python but after working with it for better half of a year now it is often a bit tiring as you've pointed out. It feels a bit like a patch to the language rather than a feature even with the newest 3.9 version.
Btw you might like https://trio.readthedocs.io which makes asyncio much more bearable!
OT Question : When choosing a stack for creating sites, would you choose Django over ASP.NET Core or PHP? If so, why?
For simpler sites Laravel vs Django probably just comes down to which ecosystem you are most familiar with.
I'm surprised the discussion has derailed into whether or not to use JSON fields... Certainly you don't have to, but they've been in Postgres contrib for a long time. Async views have dropped, and that is genuinely exciting. It's taken a lot of work, and there's still a ways to go before Django is truly async native, but this is one of the big steps, and being able to do some concurrent IO on a few routes could be a…
I'm surprised the discussion has derailed into whether or not to use JSON fields... Certainly you don't have to, but they've been in Postgres contrib for a long time. Async views have dropped, and that is genuinely exciting. It's taken a lot of work, and there's still a ways to go before Django is truly async native, but this is one of the big steps, and being able to do some concurrent IO on a few routes could be a…
Earlier quoted context omitted.
async is cool for I/O bound operations. You don't have to wait the request/response to finish in order to start processing another request. Talking with a db, or doing http requests are IO operations, so instead of blocking the process, django can now start processing another one. When the IO operation is done, it continues where it stopped.
Why would Django not be able to process other requests while one process is waiting for IO? I don't know much about Python, but in a typical PHP/Apache setup, Apache simply starts as many processes as needed to answer all requests.
In python world you have few Django processes spawned by WSGI/ASGI app container, and those processes spawn python threads to handle requests. Because python uses GIL, no more than single thread is executed at single time per process. At specific times GIL stops running bytecode for one thread and moves to next one (eg when you do IO). This means other threads keep running, but in theory you can run out of threads.
In async you use tasks instead of threads for http requests, so single process can handle multiple requests at same time, only spawning threads at limited number of situations.
Earlier quoted context omitted.
Can you please elaborate on the "wealth of tooling" part? Makes me wonder what I don't know...
Some useful ORM extensions that I know of include: - Core Forms and Class-based views - https://django-extensions.readthedocs.io/en/latest/model_ext... - https://django-model-utils.readthedocs.io/en/latest/ - https://django-queryable-properties.readthedocs.io/en/stable... - https://django-mptt.readthedocs.io/en/latest/ - https://rsinger86.github.io/django-lifecycle/