I'm a fan of WSGI. It has allowed a large number of frameworks to explore different methodologies while (mostly) abstracting away the deployment pieces. For instance I can deploy a django app the exact same way I would deploy a flask app.
I have not had a chance to play with ASGI yet. I'm not a fan of async as a paradigm, but it has a small number of use cases where it excels. I think it will always be problematic when you need heavy database access (like in most django apps), but where it does fit it can be a very handy tool.
About the only nitpick I can think of is that dealing with large streams of data (say a user-agent uploading a big file) without either the web server / or the WSGI side of things reading the whole thing into memory or buffering it on disk can be a pain.
It seems that there are very few breaking changes in Django 3 that will be relevant for application developers. Third-party packages poking around in Django's internals might have a slightly harder time, but it still seems very managable.
You should take your car for an oil change regularly. You should go to the dentist every 6 months. And you should consider updating your software dependencies when they announce end-of-life sometime over the next 10 years. It's been 10 years.
What are you talking about? Django maintenance policy is clear as day, extremely mature with predictable deprecation cycles with plenty of heads up.
Code is alive and needs maintenance. Period. You cannot expect simultaneously a modern framework with eternal backwards compatibility and security gaps.
As someone who built his business on django, I'd say I'm super happy with it. However, my biggest gripe with it is it's continued push for updates with breaking changes.
Moving from django 1/python 2.7 was quite painful but possible and now they're suggesting that third party developers stop supporting django 2.2? It was released in April this year!
I know I'm not using any new django features that weren't there in 1.0. I imagine most django users are the same. I'd love to just have a LTS with security updates and conservative non-breaking changes.
When I run my tests with python -Wa I get a lot of warnings that seem to come from inside Django. Is this caused by my code? How can I silence them?
/home/cody/.virtualenvs/37/lib/python3.7/site-packages/django/db/models/sql/compiler.py:1030: RemovedInDjango30Warning: Remove the context parameter from MultiSelectField.from_db_value(). Support for it will be removed in Django 3.0.
RemovedInDjango30Warning,
/home/cody/.virtualenvs/37/lib/python3.7/site-packages/django/db/models/sql/compiler.py:1030: RemovedInDjango30Warning: Remove the context parameter from MultiSelectField.from_db_value(). Support for it will be removed in Django 3.0.
RemovedInDjango30Warning,
A quick Google search suggests that this is caused by the django-multiselectfield package, which seems unmaintained (it hasn't been updated for 2 years) and doesn't claim to be compatible with Django 2 or 3.
Given companies are still using old versions of IE in 2019 or are forced to use compatibility mode with hinting falling back to IE 7,8,etc engine I feel like jQuery is more of a commodity than writing custom code for certain scenarios.
I also thought we would've been better off without jQuery until I started receiving calls that multiple users with different browsers had problems with the app... and telling the users to update would either need approval from the IT department or the user refuses because it'd break compatibility with existing legacy apps that they also use. Having jQuery is just a cheap price to pay.
Ideally I would love everyone to be on the latest browser and that companies moved out of said legacy apps or at least invested in improving them...
I like django, I really do. But the other day I had to reinstall a site built with Django 1.4 and was disappointed to find that the docs for it are no longer online :-(
I didn't think to google because https://docs.djangoproject.com/en/1.4/ 404s (and it was 4am). At least they're still online somewhere (but on the main site or a link to RTD would have been handy)
Good point. I wonder how you would notify the Django team about simple things like that. They do get commercial backing so I think they have capacity to maintain old documentation as a matter of good habit.
Django is a better monolithic framework. But in Python world users will be equally productive with any WSGI or ASGI based framework.
With Django 3.0 alpha there is an issue with orm which is still not async, so not sure how mixing async code with sync code will behave.
Personally I haven't moved to any async framework in Python for project which need db access until the database adapters like psycopg and orm like sqlalchemy support them completely.
Now a days since most of my startup work involves developing REST API using Python backend without worrying about templates prefer micro framework like Flask [1], bottle [2], web.py [3], Pyramid [4], TurboGears 2 [5], cherrypy [6] etc.
For async might use uvloop based micro framework like sanic [7], quart [8], or starlette [9] vibora [10] etc.
These days in development we try to use these framework more like a library than framework per se. The difference is using them as library our code call library code and it's inline with one of the zen of python "Explicit is better than implicit".
It will trigger an error to review the code. It still is bit of a trouble to debug async code with sync code.
"Note that as a side-effect of this change, 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. If you were using Django from async code before, this may trigger if you were doing it incorrectly. If you see a SynchronousOnlyOperation error, then closely examine your code and move any database operations to be in a synchronous child thread."
I'm really pleased to see Django is still going strong. I started using it since version 0.96 and have been in love ever since.
I'm currently supporting two major business applications built on Django (custom ERP/CRM software) and the speed with which our teams can develop new features is astounding.
40 comments
[ 2.5 ms ] story [ 77.4 ms ] threadI have not had a chance to play with ASGI yet. I'm not a fan of async as a paradigm, but it has a small number of use cases where it excels. I think it will always be problematic when you need heavy database access (like in most django apps), but where it does fit it can be a very handy tool.
About the only nitpick I can think of is that dealing with large streams of data (say a user-agent uploading a big file) without either the web server / or the WSGI side of things reading the whole thing into memory or buffering it on disk can be a pain.
The cost of maintenance is very high in the Python/Django stack those days!
https://docs.djangoproject.com/en/1.11/topics/python3/
True, but the community has done a great job managing this over a long period of time. It's most costly if you haven't been investing along the way.
It seems that there are very few breaking changes in Django 3 that will be relevant for application developers. Third-party packages poking around in Django's internals might have a slightly harder time, but it still seems very managable.
https://www.python.org/dev/peps/pep-0373/
Code is alive and needs maintenance. Period. You cannot expect simultaneously a modern framework with eternal backwards compatibility and security gaps.
Moving from django 1/python 2.7 was quite painful but possible and now they're suggesting that third party developers stop supporting django 2.2? It was released in April this year!
I know I'm not using any new django features that weren't there in 1.0. I imagine most django users are the same. I'd love to just have a LTS with security updates and conservative non-breaking changes.
Prior to 2.2, so they encourage keeping support for the Django 2.2 LTS.
The current LTS (1.11) ends in April 2020, which gives you a little more than 6 months to upgrade current projects to 2.2.
Alternatively, if you find a package import is causing this warning, you can wrap the import in a context manager that ignores the warning:
Is there a plan to stop requiring jQuery?
I also thought we would've been better off without jQuery until I started receiving calls that multiple users with different browsers had problems with the app... and telling the users to update would either need approval from the IT department or the user refuses because it'd break compatibility with existing legacy apps that they also use. Having jQuery is just a cheap price to pay.
Ideally I would love everyone to be on the latest browser and that companies moved out of said legacy apps or at least invested in improving them...
https://django.readthedocs.io/en/1.4.X/
But I strongly recommend you update ASAP, as v1.4 is likely to be riddled with security holes...
Your best option is to go to this page to understand the upgrade process, https://docs.djangoproject.com/en/2.2/howto/upgrade-version/
All information you need to upgrade is on that page, read it carefully.
With Django 3.0 alpha there is an issue with orm which is still not async, so not sure how mixing async code with sync code will behave.
Personally I haven't moved to any async framework in Python for project which need db access until the database adapters like psycopg and orm like sqlalchemy support them completely.
Now a days since most of my startup work involves developing REST API using Python backend without worrying about templates prefer micro framework like Flask [1], bottle [2], web.py [3], Pyramid [4], TurboGears 2 [5], cherrypy [6] etc.
For async might use uvloop based micro framework like sanic [7], quart [8], or starlette [9] vibora [10] etc.
These days in development we try to use these framework more like a library than framework per se. The difference is using them as library our code call library code and it's inline with one of the zen of python "Explicit is better than implicit".
[1] https://palletsprojects.com/p/flask/
[2] https://bottlepy.org/
[3] http://webpy.org/
[4] https://trypyramid.com/
[5] https://turbogears.org/
[6] https://cherrypy.org/
[7] https://github.com/huge-success/sanic
[8] https://pgjones.gitlab.io/quart/
[9] https://www.starlette.io/
[10] https://vibora.io/
I believe there are safeguards in place to be sure you don't accidentally do this.
"Note that as a side-effect of this change, 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. If you were using Django from async code before, this may trigger if you were doing it incorrectly. If you see a SynchronousOnlyOperation error, then closely examine your code and move any database operations to be in a synchronous child thread."
I'm currently supporting two major business applications built on Django (custom ERP/CRM software) and the speed with which our teams can develop new features is astounding.