Live data from Hacker News

Django 3.1

djangoproject.com

91–100 of 209 posts

Re: Django 3.1

#91
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.

I work mostly in Python and I like it. However, C# is a great, and for some reason underrated, language that is certainly better along a number of dimension.

I didn't downvote, but IMO it's only half true: C# and the runtime really are excellent. But the C# library ecosystem is much smaller than the Java, JavaScript, PHP, and Python ecosystems (and even Go/Rust for a lot of things), and there are even quite a few commercial (paid for) libraries! This may not matter for a particular project, but for me it's significant enough to not make C# a universal recommendation.

Hopefully it changes now that C# is open source, but for now it's quite a big downside.

Re: Django 3.1

#92
post #79

Does the ORM still write horrendous cursor based loops where simple joins would suffice?

By default yes, but you can configure queries fetching behavior using select_related/prefetch_related to avoid the N+1 queries problem.

Re: Django 3.1

#93

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.

Adding new SQL support to the Django ORM is tricky. There isn’t a nice low level abstraction for generating and composing SQL. It’s mostly a bunch of lists containing different kinds of data (strings, Col, Expression) and they don’t compose well.

On top of that, you’d need to come up with a decent frontend syntax that aligned with the existing methods.

I think Django made a mistake when first defining the language of aggregates by overloading the values() method and not using group(). To support rollup, values() would need to support it but only when used after an annotate. Not nice.

I often think about what it’d take to use alchemy for the sql building beneath the Django frontend. That would open up so many more possibilities and features.

Re: Django 3.1

#94

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.

Some use cases and background are nicely presented in this article https://wersdoerfer.de/blogs/ephes_blog/django-31-async/

HN submission: https://news.ycombinator.com/item?id=24048208

Re: Django 3.1

#95
post #77

Earlier quoted context omitted.

For a database like postgres, or even for something like SQLite, this mostly becomes a distinction without a whole lot of difference, since the database can index and access JSON structures just like regular columns.

What’s a real world example where you would choose to index the JSON as you said rather than putting them into the fields/schema.

Any time you'd otherwise use EAV.

Re: Django 3.1

#96

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.

Adding new SQL support to the Django ORM is tricky. There isn’t a nice low level abstraction for generating and composing SQL. It’s mostly a bunch of lists containing different kinds of data (strings, Col, Expression) and they don’t compose well. On top of that, you’d need to come up with a decent frontend syntax that aligned with the existing methods. I think Django made a mistake when first defining the language of…

Yea I started to bring up the existing ticket for grouping on the dev list and ask what people thought about it.

I also ended up writing a very tiny transformer function and using that directly because core only has a couple supported casts and I needed Postgres timestamp types so I could extract and rollup on the year / month / day. That gave me some insight in to some of the patterns in use in “lower level” Django differ from the expressiveness / composability of SQLAlchemy.

Re: Django 3.1

#97
post #81

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

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 evolve and adapt to changing tech landscape.

I do agree that the stability of Django has made it extremely easy to get an MVP off the ground, especially for a seasoned developer.

I have used both and somehow, the strong typing in C# puts enough constraints on me to reason about my web app as a proper app.

In Django and flask, I would often settle into thinking everything in terms of pieces of data, moreso because of the dynamic nature of Python.

Re: Django 3.1

#98

Earlier quoted context omitted.

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?

waitUntilResolved() would wait until the promises are resolved and of course let other code execute meanwhile.

Re: Django 3.1

#99
post #58

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.

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.

Re: Django 3.1

#100

Earlier quoted context omitted.

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

waitUntilResolved() would wait until the promises are resolved and of course let other code execute meanwhile.

That's an awesome function. Is it multiprocess?
Post reply on HN