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

111–120 of 196 posts

Re: Django 3

#111

Post by mkurnikov »

emptysea wrote: post #34
Pandabob wrote: post #19

This looks neat. Does anyone have experience with using type hints and mypy with Django? Any gotchas?

I gave ‘django-stubs’ a spin on a Django 2.2 project. The ORM typings and mypy plug-in worked great. ‘.filter().first()’ and similar all returned the correct types. Ran into a couple issues with the typing of ‘client.force_login()’ where the ‘user’ parameter was typed as the ‘get_django_user()’ which wasn’t the same as the custom user model I defined in the ‘models.py’. I also had issues with ‘from django.conf import…

Hi, I'm a primary maintainer of 'django-stubs'. We're going to release new version with mypy==0.750 and Django 3.0 support soon. Could you create an issue for your 'client.force_login' problem?

> I also had issues with ‘from django.conf import settings’ not being the correct type so I’d suggest changing that to ‘Any’.

This one also has plugin support, and should be working mostly correct. Fill the issue if you can reproduce, I'd love to help with that.

What's your experience with that whole "plugin has to actually run django.setup() before typecheck" thing?

Re: Django 3

#112

Post by mattrp »

petters wrote: post #100
andrewgodwin wrote: post #74

Earlier quoted context omitted.

It's worth pointing out that the ASGI support in this release is very low level, and doesn't let you write async views or anything yet. We're still working on that.

Thanks for your work on this. If I am willing to hack a bit, is it possible? What is the main obstacle? Is it all middleware?

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

Re: Django 3

#113

Post by takeda »

bicx wrote: post #5

Does Python still have performance issues? That's always been my concern when considering its adoption.

Yes it does, and almost everything else will have performance issues except assembly. With web services, chances are that you'll hit other bottlenecks before you hit it. In python you have multiple ways to optimize performance, for example use PyPy, or various libraries like Cython that compile your performance sensitive code.

That's how asyncpg can outperform[1] some libraries that you normally would think was not possible.

[1] https://github.com/MagicStack/asyncpg

Re: Django 3

#114

Post by stefano »

tclancy wrote: post #101
stefano wrote: post #78

Earlier quoted context omitted.

Django (and DRF if you use it), uses too much reflection, which doesn't play nice with type annotations. The strategy that works for me is to annotate my application code, and keep using dynamic typing when interacting with the framework.

Do the stubs for each not work for you?

When I tried them a year ago, they used "Any" a lot, especially around the ORM code (Django) and the serializers (DRF). Since those are also the parts where type checking would be the most interesting, I didn't find a lot of value in using them.

Re: Django 3

#115

Post by mkurnikov »

Pandabob wrote: post #19

This looks neat. Does anyone have experience with using type hints and mypy with Django? Any gotchas?

There's a DEP discussion going on at https://github.com/django/deps/pull/65. Though I kind of gave up on it for now, I don't believe it'll be accepted in the current state of mypy and typing ecosystem.

Try 'django-stubs' mentioned above too https://github.com/typeddjango/django-stubs, it's mostly complete. Mypy plugin inside takes care of a lot of stuff.

Disclaimer: I'm a creator of the 'django-stubs'

Re: Django 3

#116

Post by jxcl »

andrewgodwin wrote: post #87
904baf11 wrote: post #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.

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.

It's much easier to say stuff sucks than to actually get a huge project like this shipped. Thanks so much for your hard work Andrew + team!

Re: Django 3

#117

Post by m_ke »

mattrp wrote: post #112
petters wrote: post #100

Earlier quoted context omitted.

Thanks for your work on this. If I am willing to hack a bit, is it possible? What is the main obstacle? Is it all middleware?

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.

Re: Django 3

#118

Post by tabbott »

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 600 lines of code left from the original Pylons framework that actually ran).

One of the things that has been really fantastic about Django is that we're still happily using it for the vast majority of code in the project, and every time Django comes out with a new release, I read the changelog and get excited about several improvements that actually make my life better.

Overall I think we've gotten a ton of value out of Python and Django and would recommend it to anyone starting a new full-featured web application project today.

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.

Re: Django 3

#119

Post by NickBusey »

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…

Thanks for your work on Zulip, I tend to be logged into at least 3 instances at any given time. Love the treaded model.

Re: Django 3

#120

Post by takeda »

gdfasfklshg4 wrote: post #64
traverseda wrote: post #36

Earlier quoted context omitted.

I've got more than a decade of on-and-off web-dev experience, a lot of integrating data-science projects with a web-interface, and I've never seen anything like that. You have to work pretty hard to hit a CPU bottleneck, and I can't imagine how you'd do that building a simple CRUD website. Can you explain a bit more about how the people you know are hitting that bottleneck? I mean I've literally built CRUD apps on an…

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

ORM is another bad technique. It supposedly promises you that you don't need to know SQL to use, and that is true for the simplest examples, but you absolutely have to know it for anything less trivial, then you have to figure out how to write query in ORM to get a desired SQL statement (it makes it very difficult to use advanced SQL functionality), and that's not the end. ORM constantly will make unnecessary SQL queries and by default request all fields, even if you don't use them, adding additional performance bottleneck.

In my current workplace thanks to ORM we make on average 10 queries per request and at peak generate 1Gbps throughput from/to database because of those inefficiencies.

I think the way to go is SQL support in IDE, I recently saw PyCharm with DataGrip where if you configure it to connect to a database it will start recognizing SQL in string statements and start treating it like code (so you now have autocomplete, refactoring etc). I think this is probably the proper way to do it and I wish that other IDEs would have similar features.

Post reply on HN