Django 3.0 alpha 1 released | Hacker News Reader

Django 3.0 alpha 1 released

djangoproject.com

60 pointsedmorley39 comments

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".

[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/

> so not sure mixing async code with sync code will behave.

I believe there are safeguards in place to be sure you don't accidentally do this.

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."

What is a good use case for async in python? I absolutely loathe the async nature of javascript and find code much harder to follow.

Biggest news is ASGI support, which should enable a ton of new features and performance improvements in the future.

ASGI is disgusting. It's WSGI (not very good in the first place) with asyncio tacked on (even worse!).

I don't know ASGI. Could you argument please ? Your comment is not useful to me as is.

https://www.google.com/search?q=WSGI+vs+ASGI

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.

I agree, WSGI has always seemed fine to me.

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.

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.

"versions of Django prior to 2.2."

> drop support for all versions of Django prior to 2.2

Prior to 2.2, so they encourage keeping support for the Django 2.2 LTS.

I'm not sure if you're trolling, but if you're serious about having a business based on Django you should know that v2.2 have support until 2022.

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.

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 :-(

First hit when googling "Django 1.4":

https://django.readthedocs.io/en/1.4.X/

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.

It's available on Archive.org; https://web.archive.org/web/20130113152941/https://docs.djan...

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.

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.

Thanks I will look at removing this.

RemovedInDjango30Warning inherits from the python built-in DeprecationWarning, so it can ignored on the command line with:

    python -Wa -Wignore::DeprecationWarning

The above, however, will ignore all DeprecationWarning warnings. You can further filter this ignore if you know the module where the warning originates: https://docs.python.org/3/library/warnings.html#describing-w...

Alternatively, if you find a package import is causing this warning, you can wrap the import in a context manager that ignores the warning:

    import warnings
    from django.utils.deprecation import RemovedInDjango30Warning

    with warnings.catch_warnings():
        warnings.simplefilter("ignore", RemovedInDjango30Warning)
        import MODULE

Release notes here: https://docs.djangoproject.com/en/dev/releases/3.0/

> jQuery is upgraded from version 3.3.1 to 3.4.1

Is there a plan to stop requiring jQuery?

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

Right, why break compatibility when you don't have to?

Why? It doesn't so much "require" it, Django includes jQuery for the admin pages.

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.

Migrate to python 3. Migrate to Django 3. Migrate to next version of Django Rest Framework.

The cost of maintenance is very high in the Python/Django stack those days!

If you're using python 3 upgrading django should be really easy. DRF and Django haven't had any major breaking changes in a long time.

Hasn’t Django supported Python 3 for a few years?

https://docs.djangoproject.com/en/1.11/topics/python3/

> The cost of maintenance is very high in the Python/Django stack those days!

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.

There's a list of breaking changes in the release notes: https://docs.djangoproject.com/en/dev/releases/3.0/#backward...

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.

Management commands, migrations and ORM from Django can be used with other web frameworks like Falcon, Flask. It can reduce maintenance a lot.

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.

https://www.python.org/dev/peps/pep-0373/

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.

Could anyone provide a bit of context about what asynchronous features are coming and how they compare to how, say, Node handles asynchronous actions?

ASGI, finally! I was so happy to see the first alpha newreleases.io notification for version 3.

Reply on news.ycombinator.com