Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 3.1

djangoproject.com

Post reply on HN
Print view View original

171–180 of 209 posts

Re: Django 3.1

#171

Post by mixmastamyk »

kumarvvr wrote: post #97
moksly wrote: post #81

Earlier quoted context omitted.

I work in a C# shop that has added Python to our development, because it runs a long side the poweshell scripts our operations guys build in the managed azure services. I think Django is just a good package. It’s really productive and the ORM is better and easier to use than entity. The real winner for me is it’s stability though. In the time we’ve gone from classic ASP to web-forms to MVC to modern MVC to .net Core…

Curiously, while Django has not changed much, Asp.net has evolved. The new endpoint routing system is very flexible. The DI system is good and templating is excellent. Additionally, it has amalgameted into a hybrid framework, where adding a high performance API to an existing MVC app has become trivial. Not to mention, the excellent language and support for tech like gRPC. On the whole, Asp.net core looks poised to e…

If the team/project is huge typing has benefits. If not, python type hints are generally good enough. In the end using MS tooling means their needs come first and so that is to be avoided.

Re: Django 3.1

#172

Post by pythonaut_16 »

kabacha wrote: post #145
Xixi wrote: post #23

Earlier quoted context omitted.

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…

> Why do I have to decide if my function is synchronous or not when I write it? 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 al…

Is that because the Python interpreter has to explicitly handle coroutines differently from normal functions?

One difference for Elixir/Erlang (which GP mentioned) is that the BEAM VM can interrupt any function by default. (There's a few exceptions when you deal with native code and other things)

Re: Django 3.1

#173

Post by pythonaut_16 »

martpie wrote: post #12
konschubert wrote: post #4

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.

Async operations have never been to speed things up, but to prevent synchronous operations from blocking threads. This should have no (big) performance impact, but these will most probably allow better concurrency, which can be quite critical for a web framework.

Which should allow a Django instance to serve more concurrent requests.

Making views async won't do much to make an individual request faster (besides keeping it from being blocked by other slower requests).

Re: Django 3.1

#174

Post by zelphirkalt »

WD-42 wrote: post #156
d33 wrote: post #8

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…

I'm sorry, but this is just programming. You have two choices: 1. Never upgrade and keep everything stable but go through hell when you inevitably must update something or 2: keep up with the latest and go through some minor pain with every release. It's a lot like taking care of a house or car. The world does not stand still, much less programming frameworks.

Hmmm, with well chosen, thought through abstractions, which only presume the minimum they need to presume about their usage, the frequent changes you describe are not a given.

The question is, what it is, what frequently needs to change and why no appropriate abstraction has been found to reach stability.

Re: Django 3.1

#175

Post by tus88 »

btown wrote: post #147
sammorrowdrums wrote: post #144

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…

As an FYI: Using a gevent monkey patch has been a way to get async Django for years. Overhead is inefficient in CPU cycles and you need to stay away from doing CPU bound things like Numpy manipulations, but for an app server that’s bound by external API call latency, it practically gives infinite concurrency compared to a thread-per-request model. And no need to worry about event queues. You can feel free to synchron…

gevent should be in core.

Re: Django 3.1

#176

Post by Daishiman »

djaychela wrote: post #143
d33 wrote: post #8

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…

I'm only a beginner with Django, but I tend to agree to a point - reason being is that I've found old code that I want to use (github, etc.), but it targets Django 1.x (later versions, say 1.10), and will use a load of stuff which is now removed. The issue I've had is that the documentation seems to be difficult to find these removed elements - such as last week, looking for the {% ssi (file) %} tag, which it took me…

Sorry, but Django is the best framework I've found for managing deprecations.

In the web world it's quite frequent to have major versions every couple years that break everything and require substantial dev cycles to keep up.

That said, 1.x applications are quite old by now.

Re: Django 3.1

#177

Post by Daishiman »

anentropic wrote: post #126
whouweling wrote: post #75

Earlier quoted context omitted.

Yes; gevent does also fix this problem. But it also gives you a lot of new problems when running all requests async. In my experience mostly with views that (in some specific calls, i.e for a specific customer) keep the cpu tied up, for example serializing a lot of data. Random other requests will be stuck waiting and seem slow while it is a lot more difficult to find out which view is the actual problem. I have depl…

How does async/await solve this? I would have thought it has exactly the same problem?

It does have the same problem. Standard library CPU-heavy functions are not generally async-friendly. You'll be stuck blocking for that 500kb JSON file to serialize.

Re: Django 3.1

#178

Post by Daishiman »

doteka wrote: post #161
yebyen wrote: post #151

Earlier quoted context omitted.

This is a hot-take from Aaron Patterson, Rails and Ruby core team dev, in his keynote this year where he addressed a very similar idea on a perhaps related query generation topic... https://youtu.be/9JEEabL90AA?t=1360 To give you the tl;dr (he goes through profiling and a great deal of data to help show what a core dev needs to do in order to help us solve this one specific case, and...) Aaron comes to the conclusion…

While a good point, I would say the problem is caused by ORMs existing. Somehow somewhere we decided that a person who thinks SQL is too difficult should be using a database.

Nobody who builds an ORM thinks that.

An ORM saves experienced SQL users from having to write boilerplate SQL and hack on their own garbage ORM, which is what any large project ends up doing, attempting to compose queries and filters in vain.

I have never ever heard of ORMs as an argument to avoid learning SQL, and AFAIK no author of well-known ORMs holds that opinion.

Re: Django 3.1

#179

Post by madelyn »

leetrout wrote: post #78

I hope they prioritize some support for ROLLUP and friends. I’d never used it before and it was fantastic but I had to drop down to raw sql to do it. SQLAlchemy has had support for well beyond a year. I’ve used Django since 2008 and I love it with all its warts but I’ve really grown to prefer SQLAlchemy.

Give aldjemy a try! You can construct sqlalchemy queries/sql in general from your Django models. It's amazing and magical for complex queries!

Re: Django 3.1

#180

Post by madelyn »

jungletime wrote: post #162

Something I wish that Django did was user defined functions in the template. It has for loops, which is good but it forces you to write the html in top to bottom procedural manner. It would be far better to be able to define a function that you can call for bits of html code that might repeat in the same template. Since I stopped using Django at 1.6 does the new version let you define functions in the templates?

I wrote a little library that does exactly this, though it's framework agnostic. I agree being able to use components in Python for webdev is nice.

It's called "dashml" on PyPi if anyone is interested. I mostly use it in Django and haven't worked on it lately cause of $DAYJOB though.

Post reply on HN