Live data from Hacker News

Django 3

docs.djangoproject.com

121–130 of 196 posts

Re: Django 3

#121
Having worked with Asynchronous python since the days of twisted, tornado - I haven't really found any real reason to switch to asyncio. Generally speaking the old forms of async syntax (@coroutine, @inline_callback) make it incredibly clear that you are executing code well outside of a sequential paradigm - they force you to think a little more about what is going on.

The idea of Django throwing errors when you try and run async unsafe code within an event loop gives me cause for concern. I can just imagine folks who don't understand adding 'yield', 'await', 'yield from' until the errors go away - while being confused with the resulting execution. I think there is always a place for synchronous code in Python - I think Django should lean in to the simplicity afforded by it.

Last note - I also am very weary to mix asynchronous code with other primitives like threading, multiprocessing. If I am going the route of async programming - I usually just intend to optimize a single thread - and then I leave it up to the OS to optimize across multiple processes.

Re: Django 3

#122

Zulip has been powered by Django since the very early days of its development with Django 1.4, back in 2012. As a reasonably mature web application with significant scale, we're at the stage in many companies' development where one starts to rip out more and more of the web framework to optimize things or just make them work the way we want. (E.g. while I was at Dropbox in early 2016, we discovered we only had about…

Zulip is quite amazing and I really like the product, however I somewhat dislike that the installer is a complete machine take over with many hard-coded paths.

Supporting only Ubuntu releases is one thing, but the code base actively fights installing it on anything else but the supported distributions (ubuntu). At which point, why even have a installer, just ship an image.

Since Zulip has so many moving components, I would love to see it be installed with something like Nix. Doing so would allow it to be installed in a consistent way across many different OSes, and decouple your reliance on software provided by the OS. It would also make upgrades seamless.

You can install nix on any single linux distribution, not just nixos, and since your installer already hard requires running as root, you can install nix and then install zulip in nix.

Re: Django 3

#123
Just want to say thank you to the Django core team. I was privileged to use Django full time for over 6 years. Both the project and the community are a joy.

There's a few times I had to dive into Django's internals, and every time it was logical and straight forward to understand and modify.

Thanks guys!

Re: Django 3

#124
post #38

I have been using FastAPI for the last two months (which also is an ASGI server and makes full use of annotations and type hints with mypy) and the experience has been incredible. ( https://fastapi.tiangolo.com/ ) If Django can now also support annotations and async code I dream of an scenario where apis can be built using this two elements. Does anybody know a good resource to learn/catch up with this release?

It's worth pointing out that the ASGI support in this release is very low level, and doesn't let you write async views or anything yet. We're still working on that.

Thanks for the info. I'll probably start fiddling with Django again, it has sure been a while for me.

Also, thank you and all the contributors for such amazing resource.

Re: Django 3

#125

Zulip has been powered by Django since the very early days of its development with Django 1.4, back in 2012. As a reasonably mature web application with significant scale, we're at the stage in many companies' development where one starts to rip out more and more of the web framework to optimize things or just make them work the way we want. (E.g. while I was at Dropbox in early 2016, we discovered we only had about…

One of my favourite things with Django has been their mature approach to changes. Want to be guaranteed a stable upgrade? Step 1: Fix deprecation notices. Step 2: Upgrade. (If you're upgrading over a few releases, return to step 1). Coming from other frameworks it's a delight :) At least that's been my experience with smaller projects. I'm curious, does that line up with your experience with Zulip, too?

Re: Django 3

#126
post #41

Was really excited to upgrade but the async safety check makes the ORM unusable in a Jupyter Notebook. https://stackoverflow.com/questions/59119396/how-to-use-djan... https://forum.djangoproject.com/t/is-there-a-way-to-disable-...

The ORM has been essentially unusable from my perspective since day 1

Re: Django 3

#127

Zulip has been powered by Django since the very early days of its development with Django 1.4, back in 2012. As a reasonably mature web application with significant scale, we're at the stage in many companies' development where one starts to rip out more and more of the web framework to optimize things or just make them work the way we want. (E.g. while I was at Dropbox in early 2016, we discovered we only had about…

One of my favourite things with Django has been their mature approach to changes. Want to be guaranteed a stable upgrade? Step 1: Fix deprecation notices. Step 2: Upgrade. (If you're upgrading over a few releases, return to step 1). Coming from other frameworks it's a delight :) At least that's been my experience with smaller projects. I'm curious, does that line up with your experience with Zulip, too?

Yeah, that matches my experience; their documentation on upgrades is excellent, and there's generally only issues not covered by their deprecation notices in places where you were doing something not supported by the documented API (E.g. monkey-patching, subclassing to override something, etc.), and even then, they often comment if it's a common type of modification.

Re: Django 3

#128
post #24

Earlier quoted context omitted.

I mean, what kind of performance issues were you running into? You're not going to get maximum performance out of a python program, generally. But unless your python program is using 100% cpu that's not really an issue, and there are very few cases where I'm using python and it's CPU that's slowing down the program. Mostly it ends up being some kind of IO. If you're looking to do complicated mathematical operations,…

In my experience most people creating CRUD websites with Django will hit a CPU bottleneck.

just going to post my usual answer to these types of comments: if it's good enough for Instagram, it's good enough for us.

Re: Django 3

#129
post #38

I have been using FastAPI for the last two months (which also is an ASGI server and makes full use of annotations and type hints with mypy) and the experience has been incredible. ( https://fastapi.tiangolo.com/ ) If Django can now also support annotations and async code I dream of an scenario where apis can be built using this two elements. Does anybody know a good resource to learn/catch up with this release?

Pyotr [0] is a small library I've been developing for a while, based on Starlette. In a nutshell, it takes an OpenAPI specification and turns it into an API application, taking care of all the routing and validation according to the spec. It is conceptually similar to connexion [1], but it supports async and is Python 3 only. There is also a client component, in the spirit of bravado [2]. [0] https://pyotr.readthedoc…

What's the difference from fastAPI? https://fastapi.tiangolo.com/

Re: Django 3

#130

> Django is now aware of asynchronous event loops and will block you calling code marked as “async unsafe” - such as ORM operations - from an asynchronous context. So DB calls aren't async?

Correct - the Django ORM is not (yet) async.

The asyncpg library[1][2] could be used for direct, asynchronous database access, from within a Django 3.x app.

The asyncpg library is a low-level async Postgres adaptor, similar to psycopg2, except that it provides much better abstractions and automatic encoding / decoding (vs just piping bytes back and forth like psycopg2), not to mention it is much faster than anything else out there. IOW, asyncpg would serve as a much better foundation for a future ORM. My best guess is that, in the future, Django's ORM will be refactored to optionally support async and will supply an adaptor for asyncpg.

1. https://github.com/MagicStack/asyncpg

2. https://magicstack.github.io/asyncpg/current/

Post reply on HN