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

51–60 of 209 posts

Re: Django 3.1

#51

Post by tarkin2 »

kumarvvr wrote: post #13

OT Question : When choosing a stack for creating sites, would you choose Django over ASP.NET Core or PHP? If so, why?

PHP on its own was more of a templating system plus arbitrary code when I used it. Django and ASP.NET have ORMs and templating systems.

Lots of people love ORMs although I’ve found complex queries slow with a hefty object model system, to the point where I’d rather write parameterised sql queries than work with a ORM optimization strategy.

The templating system is nice although these days I mostly use javascript talking to json endpoints, with nearly zero need for a templating system.

Honestly when your need is: “javascript talks to endpoint and endpoint talks to database” I don’t see a greater need than python, nodejs, golang or whatever language you prefer plus a couple of libraries. Most server frameworks add more stuff you probably don’t need, unless you can’t work without an integrated ORM.

Re: Django 3.1

#53

Post by Alex3917 »

metafunctor wrote: post #27
grenoire wrote: post #6

JSONField has been an absolute godsend in combination with Django's ORM. I had been using it with Postgres and will likely keep our backend the same, but I cannot recommend it enough. You will have to write some validation and schema code on top if you want your data to have similar (but weaker) guarantees to the usual typed fields; the benefits from the flexibility you get are immeasurable though.

In projects I've been involved with, storing JSON in the database has often turned out to be a mistake. Django models create a well-defined self-documenting structure for your schema, are easy to evolve using migrations, and there's a wealth of tooling built on top. IMHO, these far outweigh the perceived convenience of simply storing some stuff in a JSON field. If you find yourself implementing your own validation an…

> If you find yourself implementing your own validation and schema code for JSON fields, I'd say it's a sign that you should probably stop and migrate the data to Django models instead.

Don't agree. Where JSON fields with validators are useful is when you would otherwise have inherited models for different variants of the same type of thing. It's a lot easier to understand and query one model with 50 Cerberus (or whatever) schema validators than it is to understand and query 50 Django models. With the JSON approach it leaves one part of the codebase that's complicated to understand, but you mostly shouldn't need to understand it. Whereas when you have tons of different models and each one needs to be used in different places and is queried in different ways and has its own serializers, the mess tends to spread throughout the entire codebase.

Re: Django 3.1

#54

Post by nurettin »

FreeHugs wrote: post #52

What would be a typical use case for "Asynchronous views"?

it would be useful if your code has to execute async code and await it's result from within a view. For example: create 10 tasks and return await asyncio.gather(*tasks) as json.

Re: Django 3.1

#55

Post by FreeHugs »

nurettin wrote: post #54
FreeHugs wrote: post #52

What would be a typical use case for "Asynchronous views"?

it would be useful if your code has to execute async code and await it's result from within a view. For example: create 10 tasks and return await asyncio.gather(*tasks) as json.

I don't know much about Python's async tools, but why couldn't that be done in a non-async view?

In pseudo code I would think it would look like this:

    def my_view(request):
        name = async_get_name() // returns a promise
        city = async_get_city() // returns a promise
        waitUntilResolved(name,city)
        return HttpResponse('Hello '+name+' from '+city)

Re: Django 3.1

#56

Post by waihtis »

StavrosK wrote: post #41
waihtis wrote: post #34

Earlier quoted context omitted.

re-read the documentation but I'm not following. This example: async def current_datetime(request): now = datetime.datetime.now() html = ' It is now %s. ' % now return HttpResponse(html) seems like an example that I was thinking of.

I don't know what you're thinking of, unfortunately, but that piece of code just returns the current date when you visit the page.

After taking a uninterrupted reading slot to understand the async views, you're right, and I had the concept understood wrong.

Re: Django 3.1

#57

Post by nurettin »

FreeHugs wrote: post #55
nurettin wrote: post #54

Earlier quoted context omitted.

it would be useful if your code has to execute async code and await it's result from within a view. For example: create 10 tasks and return await asyncio.gather(*tasks) as json.

I don't know much about Python's async tools, but why couldn't that be done in a non-async view? In pseudo code I would think it would look like this: def my_view(request): name = async_get_name() // returns a promise city = async_get_city() // returns a promise waitUntilResolved(name,city) return HttpResponse('Hello '+name+' from '+city)

It could be done with anything, but async view lets other code execute while it is waiting for IO, what does waitUntilResolved do?

Re: Django 3.1

#58

Post by woile »

FreeHugs wrote: post #52

What would be a typical use case for "Asynchronous views"?

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.

Re: Django 3.1

#59

Post by StavrosK »

waihtis wrote: post #56
StavrosK wrote: post #41

Earlier quoted context omitted.

I don't know what you're thinking of, unfortunately, but that piece of code just returns the current date when you visit the page.

After taking a uninterrupted reading slot to understand the async views, you're right, and I had the concept understood wrong.

Yeah, I think you were thinking some sort of auto-refresh.

Re: Django 3.1

#60

Post by jpgvm »

nix23 wrote: post #46
jpgvm wrote: post #29

Earlier quoted context omitted.

Then ASP.NET is probably the superior choice. C# is a better language by far and the .NET runtime is a better runtime by far. It only ever makes sense to use Python for data-science one-offs and munging if you have competency in Java/C#/etc. It's not a language well suited to application development.

>C# is a better language by far and the .NET runtime is a better runtime by far. Big nono!!

I don't see how this is controversial...

C# is a powerful language that is highly expressive, has a great type system, excellent compiler and great IDE, excellent async support, fast HTTP stack in standard library, blessed application development framework and object relational mapper, etc. Basically everything you could ask for in an ecosystem for developing a long-lived web application.

Python is a scripting language which is great for one-offs and has great data-science libraries but lacks static typing, poor IDE experience, slow runtime performance, poor portability because of it's reliance on FFI, poor long-term application maintenance track record, no blessed frameworks, competing and incompatible async solutions, etc.

Tbh I don't think there is much contest. Yes you can write a bunch of Python quickly that will do something but if you already know C# which is much better suited for the task it's clearly a better choice.

Post reply on HN