Earlier quoted context omitted.
Not Groovy, Python! :)
Adding a smiley doesn't negate that your comment was unnecessary and of no added value to the conversation.
It a reference to the Groovy language - http://groovy-lang.org/
Django 3
51–60 of 196 posts
Re: Django 3
#52For 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.
My experience has been that the easiest method is to to upgrade one minor release at once (e.g. in your case I'd do 1.11 -> 2.0 -> 2.1 -> 2.2 -> 3.0). This has almost always gone quite smoothly, but it is somewhat tedious.
That said, jumping a bunch of releases (e.g. 1.11 -> 3.0) actually often works out just fine, especially if I've got good test coverage. It's just that when it doesn't work, it can be tricky to find out what's going wrong. That's because the release notes are typically written with just a single step in mind, so with a bunch of releases I find myself scrambling to figure out which set of notes I need to read.
Re: Django 3
#53Right 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…
Perhaps it's time to think about ditching the "batteries included" monolithic frameworks like Django (Rails etc.) and start your serverless/microservices/docker/k8s/etc journey. The beauty of this type of architecture is that you don't need to worry about upgrading your entire stack just because your underlying framework bumped a version number. You can create a service w/ Pylons here, a service w/ Whatever there, an…
No.
You push all your complexity to your infra, where you end up having an order of magnitude less visibility, way more problems debugging trivial issues, and making your life more difficult for dumb, simple problems that have been solved two decades ago.
Monolithic frameworks are amazing. They have well-designed APIs by people who don't want to waste time upgrading to the latest framework of whatever, and splitting them into actual services is equally complicated provided you've architected them well. And you haven't, it's as much of a PITA as any "serverless" thingy of the day.
Re: Django 3
#54I 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?
How hard was the learning curve? What are the main benefits over Django?
Learning curve is super low. Main benefits are:
1. Performance, it's a wrapper on top of starlette/uvicorn, which brings the performance closer to nodejs (https://www.techempower.com/benchmarks/#section=data-r17&hw=...). (I did run into some issues with it though due to the default response validation when serializing large response bodies)
2. Lightweight background tasks (from starlette)
3. Documentation generation from type annotations.
It's a nice tool for microservices but coming from django you'll have to roll your own database management, authentication, sessions, caching, admin and etc. I'm also not a fan of the magic request unpacking using type annotations and prefer getting a request object as is done in django and starlette. IMHO most people would probably be better off with plain starlette and a 3 line decorator to handle request validation and response serialization.
Re: Django 3
#55Earlier quoted context omitted.
> i.e. only use the most basic and generic Django features I don't think you need to do this with Django. Features are generally very mature, stable, and are not deprecated frequently. When they are, they are deprecated years in advance with long term support still provided. In all honesty, I've seen very few projects run feature lifecycles as well as Django. I'd use everything you need to in it without concern about…
Seconded, I haven't really had many problems upgrading Django projects, and I've upgraded a lot of them.
Yep. I work on a codebase started with 1.4 and we're on 2.2 now, and almost all of that was straightforward. The biggest difficulty was migrating from South to Django migrations, and that was only because we did it between real releases on Django's master branch (we don't do that anymore!).
Re: Django 3
#56I 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 wrote a package that allows use of type annotations for validation/serialization in Django Rest Framework: https://github.com/rsinger86/drf-typed-views
(Partly inspired by FastAPI)
Re: Django 3
#57Earlier quoted context omitted.
How hard was the learning curve? What are the main benefits over Django?
Learning curve is super low. Main benefits are: 1. Performance, it's a wrapper on top of starlette/uvicorn, which brings the performance closer to nodejs ( https://www.techempower.com/benchmarks/#section=data-r17&hw=... ). (I did run into some issues with it though due to the default response validation when serializing large response bodies) 2. Lightweight background tasks (from starlette) 3. Documentation generatio…
It looks pretty similar to flask as far as syntax goes.
Why do you think plain starlette is better? Are the type annotations annoying to debug?
Re: Django 3
#58Does Python still have performance issues? That's always been my concern when considering its adoption.
Yes and no. The Python interpreter/bytecode-VM is not as fast as it could be, because only a few people work on it. PyPy is great, but not drop in. Lack of funding is the proximate cause, of course, but that's just masking the ultimate cause of lack of interest. Because people use Python as a glue, just like PHP, or Node. To do the heavy lifting you have many options. (Even in Python, you can just use Cython, use FFI…
> PyPy is great, but not drop in.
Nowadays it works correctly with almost all C modules. Mostly you just need to use `pypy3 -m pip install foo` instead of `python3 -m pip install foo`.
Re: Django 3
#59For 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.
My experience has been that the easiest method is to to upgrade one minor release at once (e.g. in your case I'd do 1.11 -> 2.0 -> 2.1 -> 2.2 -> 3.0). This has almost always gone quite smoothly, but it is somewhat tedious. That said, jumping a bunch of releases (e.g. 1.11 -> 3.0) actually often works out just fine, especially if I've got good test coverage. It's just that when it doesn't work, it can be tricky to fin…
I recently went from 1.11 -> 2.0 -> 2.1 -> 2.2 over the course of about a week, deploying to production each time we had all test passing to ensure there wasn't anything amiss. There were actually relatively few changes to get there, the upgrade to Python 3 was a bigger (albeit still manageable) change. I'm expecting very few changes to get onto Django 3.0, will probably wait till the first bug fix release though as it tends to catch a few things.
The best thing to go is run the dev server with `python -Wd` to get the depreciation warnings, and fix them before each upgrade. Worked perfectly!
Re: Django 3
#60Earlier quoted context omitted.
Learning curve is super low. Main benefits are: 1. Performance, it's a wrapper on top of starlette/uvicorn, which brings the performance closer to nodejs ( https://www.techempower.com/benchmarks/#section=data-r17&hw=... ). (I did run into some issues with it though due to the default response validation when serializing large response bodies) 2. Lightweight background tasks (from starlette) 3. Documentation generatio…
It looks pretty similar to flask as far as syntax goes. Why do you think plain starlette is better? Are the type annotations annoying to debug?
I had a few endpoints that had to handle url parameters, query parameters, http headers and bodies which could either be json, form data or files, handling all of those options using type annotated parameters ended up being pretty messy and I ended up just using the starlette request object.
I was trying it out for a machine learning service that had to send back large dense vectors and I hit some other performance issues (like https://github.com/tiangolo/fastapi/issues/360#issuecomment-...), due to the coupling of validation with serialization.