Live data from Hacker News

Django 3

docs.djangoproject.com

81–90 of 196 posts

Re: Django 3

#81
post #26

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 work as a contractor and have codebases in python, f#, delphi, swift, obj-c and now rust. > "I wonder if there is some way of creating a ???? project and make it resilient to future??? updates and releases with minimum fuss?" - Use control version (mercurial, git, ...) in everything, including utils and side projects. - Record all dependencies somewhere in the project. - Automate the builds, so you also have how re…

>NOT USE VERY FANCY STUFF

They said "with minimum fuss". Write every non-trivial functionality yourself from scratch is the opposite of minimum fuss.

When you use something fancy, and the devs stop supporting it, worst case is you have to write it from scratch yourself at that point, or hope that an alternative exists.

Your suggestion is acting like they don't exist in the first place and write stuff yourself like fancy stuff disappeared - it is a huge hassle and investment all the same.

Re: Django 3

#82

For those on the 1.11 LTS release, and considering getting off the LTS train, I wonder whether it's a feasible upgrade path to go straight to 3.0, or if it would be smarter to go to 2.2 first.

I recently upgraded from 1.11 to 2.2 in one go. I didn't have any issue at all, besides a problem with mysql drivers. I had to switch from using PyMySQL, which is not the one recommended by Django anyway, to mysqlclient, and that caused one minor problem that was trivial to fix. Looking at the release notes for 3.0, I'd expect that if I migrated from 1.11 directly to 3.0 it would've been a smooth transition.

Of course it depends on your codebase. In the past I worked on a project which interacted a lot with Django internals, with a lot of code reflection involved. Upgrading that was a pain even between minor releases.

Re: Django 3

#83
> ASGI support

> Django 3.0 begins our journey to making Django fully async-capable by providing support for running as an ASGI application.

Bleh. ASGI is probably the worst implementation I can think of for a common async interface. Stringly-typed callbacks? async generators exist for a good reason. It's also very asyncio-centric, and asyncio is Not Good.

Re: Django 3

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

This is awesome! I'm one of the community maintainers of connexion (I added openapi 3 support), but I don't have write access to the repo, and it's been really tough to get any changes landed lately. nice work!

Re: Django 3

#85

> ASGI support > Django 3.0 begins our journey to making Django fully async-capable by providing support for running as an ASGI application. Bleh. ASGI is probably the worst implementation I can think of for a common async interface. Stringly-typed callbacks? async generators exist for a good reason. It's also very asyncio-centric, and asyncio is Not Good.

Can you explain why asyncio is not good?

Re: Django 3

#86
I've been building some fun side projects with Django lately and it's really a breath of fresh air. Normal, old, boring web applications with server side rendered html and basic forms. Sure, I can't add some super fast interactivity on my forms as easily without some json endpoints, but for most of my projects it's totally fine.

Re: Django 3

#87

> ASGI support > Django 3.0 begins our journey to making Django fully async-capable by providing support for running as an ASGI application. Bleh. ASGI is probably the worst implementation I can think of for a common async interface. Stringly-typed callbacks? async generators exist for a good reason. It's also very asyncio-centric, and asyncio is Not Good.

I'd love to hear your suggestions for changes we could make while keeping it somewhat WSGI-compatible. It took a few years to refine it to where it is now, so it's not like we just threw something at the wall.

Re: Django 3

#88
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?

See also the base starlette, which is what FastAPI is built upon and is ASGI from the ground up. https://github.com/encode/starlette

Re: Django 3

#89
post #85

> ASGI support > Django 3.0 begins our journey to making Django fully async-capable by providing support for running as an ASGI application. Bleh. ASGI is probably the worst implementation I can think of for a common async interface. Stringly-typed callbacks? async generators exist for a good reason. It's also very asyncio-centric, and asyncio is Not Good.

Can you explain why asyncio is not good?

It's convuluted, it's not structured concurrency (https://vorpus.org/blog/notes-on-structured-concurrency-or-g...), fundamentally despite being async/await a lot of networking code is based on callbacks anyway (see: asyncio.Protocol), and I've had a lot of trouble debugging code that spawn tasks because asyncio code has zero obligation to care about any of the tasks it spawns.

Re: Django 3

#90

> ASGI support > Django 3.0 begins our journey to making Django fully async-capable by providing support for running as an ASGI application. Bleh. ASGI is probably the worst implementation I can think of for a common async interface. Stringly-typed callbacks? async generators exist for a good reason. It's also very asyncio-centric, and asyncio is Not Good.

I'd love to hear your suggestions for changes we could make while keeping it somewhat WSGI-compatible. It took a few years to refine it to where it is now, so it's not like we just threw something at the wall.

> while keeping it somewhat WSGI-compatible

There's the problem. WSGI is fundamentally flawed too - it could also be using generators for a two-way communication channel instead of stringly typed callbacks.

In a world where Python has optional static type hints, it would be nice to have concrete objects passed too.

Post reply on HN