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

Django 3

docs.djangoproject.com

Post reply on HN
Print view View original

131–140 of 196 posts

Re: Django 3

#131

Post by j88439h84 »

luckycharms810 wrote: post #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…

> Having worked with Asynchronous python since the days of twisted, tornado - I haven't really found any real reason to switch to asyncio.

Agree. On the other hand, Trio (https://trio.readthedocs.io/) gives me plenty of reasons to switch.

Re: Django 3

#132

Post by Znafon »

tabbott wrote: post #118

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…

> My only frustration with this release announcement is dropping Python 3.5 support now. Because Python 3.5 is not EOL and used in LTS OS releases that have vendor support through 2021, this forces us to choose between our policy of supporting vendor OS releases until they reach EOL, not upgrading to Django 3 for the next year or more, or shipping our own Python on Ubuntu Xenial.

To be fair, I think the next LTS release of Django will be the last minor release before 4.0, 3.0 is not LTS.

Re: Django 3

#133

Post by tabbott »

georgyo wrote: post #122
tabbott wrote: post #118

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…

We've supported Debian in production since 2018, and we're close to supporting RHEL as well. And even if we only supported Ubuntu, there's a lot of benefit to providing an installer that works on every Ubuntu LTS release; most larger organizations have additional monitoring/security/backups/etc. software they want to run on every system they manage, and to make their own decisions about when to move their organization to newer major OS releases. You can also use our Docker image if you want that, but a lot of organizations don't :).

I wouldn't say the installer is actually a complete machine takeover; we're pretty cautious about using the system versions of dependencies shipped by the OS vendor. But we do __document__ that you should treat it as one, mainly for support reasons. The support experience that we currently provide is that where possible we respond to, investigate, and debug all reports of issues installing Zulip, with the goal of making it Just Work (this includes working to give nice error messages for common user errors).

Before we added those warnings in our documentation, we got tons of reports from users who were trying to do things like install Zulip in a shared hosting environment with other software that doesn't expect to share its database (etc.) with something else, and where they don't have root access. Also, investigation often determined the system in question had low RAM/disk resource limits from the shared hosting environment that meant running Zulip on that system wasn't going to work in any case.

At one time, that sort of shared hosting setup accounted for the majority of reports from folks having issues installing Zulip. Investigating those reports was a huge waste of time for our development community. We solved that problem by making our documentation recommend installing Zulip on a dedicated system. This also provides a lot of benefit in terms of our being able to do things like tune the configuration for postgres and memcached to allocate resources in an appropriate way for a Zulip installation with the system's RAM allocation.

There is occasionally discussion in the community of adjusting our approach here, but given how easy it is to get a VM or container these days, we're currently happy with guiding users to the dedicated VM/container path that we can guarantee works ~100% of the time and provide a great installation experience.

Re: Django 3

#134

Post by mattrp »

m_ke wrote: post #117
mattrp wrote: post #112

Earlier quoted context omitted.

If you’re in the hacking mode - what do you think of taking the Django orm and grafting it onto fast api - sort of like a stand-alone sqlalchemy but with all the ease and power or django’s querysets...

Django ORM is not async so using it with FastAPI would block the event loop. I guess you could wrap the calls in sync_to_async from asgiref but it wouldn't be pretty. Another option is using something like Tom Christie's orm project ( https://github.com/encode/orm ), which is a wrapper on top of sqlachemy with a django like interface.

Thanks for the suggestion - very interesting.

Re: Django 3

#135

Post by tedivm »

Ramiuz wrote: 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?

I love FastAPI. We're using it for a ton of different things right now, from machine learning model containers to API layers. It's a really easy project to get started with, and the developers have been iterating on it pretty quickly.

Re: Django 3

#136

Post by nine_k »

tabbott wrote: post #118

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…

If you don't mind: what are the key things that make Django useful for a project like Zulip?

How much does the framework help you, and where? What are the places where you have to go against the grain, if any?

Re: Django 3

#137

Post by ergo14 »

scarygliders wrote: post #6

Right as I was just about to start a new Django project... The thought going through my mind right now is "I wonder if there is some way of creating a Django project and make it resilient to future Django updates and releases with minimum fuss?" I've had to deal with ongoing and inherited legacy projects which run on Python 2.7, use the long-deprecated Pylons, for which there is no easy upgrade path other than a tota…

I just finished rewrite of big (400+K LOC) 10 year old pylons codebase to pyramid. We were able to share our models, services and 100% template code, and about 80% of view code was untouched.

What you want to do is follow this recipe:

https://docs.pylonsproject.org/projects/pyramid-cookbook/en/...

You put a 404 handler in pyramid to delegate not found views to pylons, and move views one by one.

In a pyramid tween you can push pyramid session, settings, request,response to pylons app globals. This approach works really well - you don't have to do total rewrite. You have same request/response objects, same sqlalchemy ORM, so you can certainly take advantage of that during migration. I don't think anyone at our company regreted the path we took and it was a massive codebase that was making money - no one can afford rewriting that from scratch in $WHATEVERISCOOL today solution.

It certainly is possible - if you need any hints contact me.

Re: Django 3

#138

Post by zzzeek »

takeda wrote: post #120
gdfasfklshg4 wrote: post #64

Earlier quoted context omitted.

If you do a bunch of filtering/joining etc that should be done in SQL by grabbing whole tables you can hit a CPU bottleneck... But then maybe your problems are deeper that choice of language.

That's trend that I see often. The other day I saw someone providing a response to argument that when using NoSQL database you need to plan in advance how the data is accessed (so you can pick the right key). The response was "don't you need to do that in every database?". So many people immediately dismiss relational databases, then re-implement all that functionality in their apps with various bugs and performance…

> It supposedly promises you that you don't need to know SQL to use

please support this assertion with an ORM whose documentation promises this.

> ORM constantly will make unnecessary SQL queries and by default request all fields,

as does "SELECT * FROM table" if you don't write out the fields and use a buffering database adapter (which is the case for nearly all Python database adapters), so, when using an ORM, you need to give it instructions over what columns you need to fetch. This is not unusual nor even anything a library could possibly guess for you if you do not give it this intent.

Re: Django 3

#139

Post by fjp »

luckycharms810 wrote: post #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…

I'm a really big fan of using aiohttp + aiopg + some light wrapping for CRUD APIs

Re: Django 3

#140

Post by fjp »

gonational wrote: post #130
goodoldneon wrote: post #91

> 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…

aiopg is also great and has full SQLAlchemy support
Post reply on HN