Django 2.2 • Hacker News Board

Re: Django 2.2

#161

Post by trpc » Mon, Apr 01, 2019, 7:10 PM UTC

rusbus wrote: post #151

trpc wrote: post #141

Why Django is not good, here are some of my reasons as far as I can remember: 1. mediocre routing (no nesting, all routes have to be declared in one place) 2. mediocre middleware (middleware is global) 3. mediocre ORM (easy only for very easy stuff, more pain in the ass than writing raw SQL itself when it comes to complex aggregations and joins) not to mention some of the famous ORM bugs that have been open for like…

A lot of these are pretty inaccurate, at least for modern Django. 1. I'm pretty sure that's not true if I'm correctly interpreting what you mean...You can do things like `path('myapp/', include(myapp.urls))` 4. Custom User models are now very straightforward (and recommended for non-trivial projects since it's easier to start with a Custom model that defaults to the default model for all options then modify it later)…

>A lot of these are pretty inaccurate, at least for modern Django.

I wish you state exactly which of them are inaccurate and why, I sincerely want to know and understand

>1. I'm pretty sure that's not true...You can do things like `path('myapp/', include(myapp.urls))`

so you suggest I create an "app" for every sub-route? every major and non major web framework except Django has a router where you can mount it to any parent and mount any child to it

>4. Custom User models are now very straightforward (and recommended for non-trivial projects since it's easier to start with a Custom model that defaults to the default model for all options then modify it later)[1]

maybe you're right IFF you start using a custom user model from the very beginning, if you happen to forget that, Django will make your life like a hell and will refuse to even pass startup checkups

>5. All these things are fairly straightforward and libraries like Django-Auth cover a huge set of the normal use cases.

I mean authentication tokens not Django's authentication (e.g. signin, signup)

>6. Django Rest Framework is a best-in-class solution for Rest APIs

so you suggest people throw their codebase and start rewriting for DRF?

>9. See 6.

so you suggest I rewrite my applications to DRF just to have JSON http request decoding?

Re: Django 2.2

#162

Post by 0xADEADBEE » Mon, Apr 01, 2019, 7:13 PM UTC

JJMcJ wrote: post #149

scardine wrote: post #73

What I find most curious about Django/Python is that about 30% of the new installs are for legacy Python/Django (2.7/1.11): $ pypinfo --start-date 2019-01-01 --end-date 2019-03-31 -- percent --markdown django pyversion Served from cache: False Data processed: 160.22 GiB Data billed: 160.22 GiB Estimated cost: $0.79 | python_version | percent | download_count | | -------------- | ------: | -------------: | | 3.6 | 39.…

Many many organizations are acting as if completely unaware of the EOL. I assume they will simply run on the last 2.7 release until projects are shut down.

If I had any Python 2.7 stuff, I would simply move it to Pypy which has no such obsolescence date.

Re: Django 2.2

#163

Post by ibejoeb » Mon, Apr 01, 2019, 7:24 PM UTC

trpc wrote: post #141

Why Django is not good, here are some of my reasons as far as I can remember: 1. mediocre routing (no nesting, all routes have to be declared in one place) 2. mediocre middleware (middleware is global) 3. mediocre ORM (easy only for very easy stuff, more pain in the ass than writing raw SQL itself when it comes to complex aggregations and joins) not to mention some of the famous ORM bugs that have been open for like…

Barely anything worth responding to here, but come on...

Django is probably the easiest ORM to use. It's powerful and extendible, and it is in line with Django's "batteries included" philosophy, so, for example, it requires a single-attribute primary key. That doesn't mean that you can't do composite keys; it's just that you need a surrogate. It also has very good API for custom functions and aggregates, meaning you can quickly add support for vendor-specific features, and also offers very good raw SQL support, where it will handle handle the mapping on your behalf, which is the most tiresome of boilerplate.

Re: Django 2.2

#164

Post by kriberg » Mon, Apr 01, 2019, 7:27 PM UTC

trpc wrote: post #141

Why Django is not good, here are some of my reasons as far as I can remember: 1. mediocre routing (no nesting, all routes have to be declared in one place) 2. mediocre middleware (middleware is global) 3. mediocre ORM (easy only for very easy stuff, more pain in the ass than writing raw SQL itself when it comes to complex aggregations and joins) not to mention some of the famous ORM bugs that have been open for like…

1. You can nest routes, see [1].

3. You can do arbitrary SQLs through the ORM. You can also do arbitrary SQLs with whatever joins you like and still get a model back. See [2].

4. This hasn't been an issue for some time. See [3] for how to extend and [4] how to substitute with your custom model.

5. There are libraries supporting relevant oauth providers [5] and libraries for specific protocols like ldap [6]. These are drop-in libraries that needs only basic configuration. It's also quite simple to build a custom authentication system, using whichever http header you fancy.

6. While this is somewhat true, it's not fair. There are libraries for many purposes. django-rest-framework [7] is an exceptionally good framework for creating ReST APIs.

7. There's nothing stopping you from using any other database, neither graph nor nosql.

8. Django's migration support is extremely good. If you dislike the ORM and you also want to use an external migration tool, you can easily enough just omit using models and utilize sqlalchemy instead.

[1] https://docs.djangoproject.com/en/2.2/topics/http/urls/#incl...

[2] https://docs.djangoproject.com/en/2.2/topics/db/sql/

[3] https://docs.djangoproject.com/en/2.2/topics/auth/customizin...

[4] https://docs.djangoproject.com/en/2.2/topics/auth/customizin...

[5] https://python-social-auth-docs.readthedocs.io/en/latest/con...

[6] https://django-auth-ldap.readthedocs.io/en/latest/

[7] https://www.django-rest-framework.org/

Re: Django 2.2

#165

Post by rusbus » Mon, Apr 01, 2019, 7:28 PM UTC

trpc wrote: post #161

rusbus wrote: post #151

Earlier quoted context omitted.

A lot of these are pretty inaccurate, at least for modern Django. 1. I'm pretty sure that's not true if I'm correctly interpreting what you mean...You can do things like `path('myapp/', include(myapp.urls))` 4. Custom User models are now very straightforward (and recommended for non-trivial projects since it's easier to start with a Custom model that defaults to the default model for all options then modify it later)…

>A lot of these are pretty inaccurate, at least for modern Django. I wish you state exactly which of them are inaccurate and why, I sincerely want to know and understand >1. I'm pretty sure that's not true...You can do things like `path('myapp/', include(myapp.urls))` so you suggest I create an "app" for every sub-route? every major and non major web framework except Django has a router where you can mount it to any…

Most of your notes are accurate, especially about the difficulty in bringing an old app up to speed. A legacy Django app has very different requirements from someone choosing a framework today.

For 1 it doesn't need to be an app, I just gave that example for clarity. You can include any set of urls (and can create nesting within your app if you desire). Of course, the Django folks would probably suggest that if you have so many urls that it becomes cumbersome, perhaps your app should be broken up.

6. You can DRF for individual routes and regular Django for others.

Re: Django 2.2

#166

Post by acdha » Mon, Apr 01, 2019, 7:34 PM UTC

dang wrote: post #140

[deleted] wrote: post #136

Earlier quoted context omitted.

[deleted]

Please stop also. Flamewar is not what we want here, and https://news.ycombinator.com/item?id=19545921 was as much a violation of the site guidelines as the comments you're criticizing. If someone is wrong, provide correct information and move on. If a comment breaks the guidelines, flag it and move on. In egregious cases, you're welcome to email us at hn@ycombinator.com. But please don't respond in kind or perpetuat…

Sorry about that — I deleted my last comment before your reply for the same rationale rather than wasting more time on a thread started in bad faith.

Re: Django 2.2

#167

Post by lkrubner » Mon, Apr 01, 2019, 7:35 PM UTC

scardine wrote: post #73

What I find most curious about Django/Python is that about 30% of the new installs are for legacy Python/Django (2.7/1.11): $ pypinfo --start-date 2019-01-01 --end-date 2019-03-31 -- percent --markdown django pyversion Served from cache: False Data processed: 160.22 GiB Data billed: 160.22 GiB Estimated cost: $0.79 | python_version | percent | download_count | | -------------- | ------: | -------------: | | 3.6 | 39.…

Not to bring back an old debate, but I simply want to point out the obvious: many data scientists disliked Python 3.x. I work with Python people who dislike Python 3.x, and we are still using mostly 2.7, because everyone feels comfortable with it. The upgrade seems to be a large imposition, with zero gain.

Re: Django 2.2

#168

Post by 1337shadow » Mon, Apr 01, 2019, 7:39 PM UTC

konschubert wrote: post #123

mkolodny wrote: post #121

I love Django. I've used it for the last 8 years. I'm happy to see the project is still thriving. At this point, for me Django is pretty much synonymous with Django REST framework ( https://www.django-rest-framework.org/ ). I can't imagine a better API than Django w/ REST framework. For static sites I use Django's templates. Otherwise, I just use Django w/ REST framework for my API, and to serve up index.html. My ind…

Try serving your static content from a specialized host, for example firebase hosting. Then, you don’t need to serve any static content from your API server and can do away with nginx. Use the whitenoise package for serving the Django admin pages if you still need them for administrative tasks.

Or serve statics from uWSGI (which also provides a spooler, cron and shared cachemem that works with python and Django but that's another story), here in optimized version for best results according to lighthouse:

uwsgi --plugin=python3,http,router_static,router_cache --mime-file /etc/mime.types --offload-threads '%k' --file-serve-mode x-accel-redirect --route '^/static/.* addheader:Cache-Control: public, max-age=7776000' --static-map $STATIC_ROOT=$STATIC_URL --static-gzip-all --cache2 'name=statcalls,items=100' --static-cache-paths 86400 --static-cache-paths-name statcalls"

Re: Django 2.2

#169

Post by somecallitblues » Mon, Apr 01, 2019, 7:40 PM UTC

BuckRogers wrote: post #155

nicoburns wrote: post #51

Earlier quoted context omitted.

IMO PHP's Laravel is competitive with Django. I think Django, Laravel, and Rails are really the only 3 frameworks with the levels of ecosystem and built in functionality that these 3 have (unless there's something in Java-land that I'm not aware of). ASP.NET Core is close, but the ecosystem around it is weaker.

I reviewed these sort of web frameworks some time ago and went with ASP.NET Core because of the language attached being more to my liking and industrial-strength than Python, PHP or Ruby. I go in assuming every project will be 500KLOC someday, because it can happen. I've seen codebases this large in Python, and it was no bueno. Static typing, forward migration / backwards compatibility take top priority for me. Larav…

But then you’re in Microsoft echo system. No bueno.

Re: Django 2.2

#170

Post by crimsonalucard » Mon, Apr 01, 2019, 7:56 PM UTC

Nextgrid wrote: post #150

systemspeed wrote: post #130

Earlier quoted context omitted.

As a Django enthusiast and python programmer, I often want less magic from Django, not more. This makes pyramid or flask seem tempting to me. If I wanted Rails that badly, I would simply port my code to Ruby.

Django is supposed to be the “Rails” of Python, allowing programmers who want a Rails-like experience to continue using Python instead of switching languages completely. If you don’t want “magic” then your solution is right - just use Flask.

The thing with the "magic" of django is that you don't need to use it! It's up to you whether you want to use the magic or not! The magic is powerful. The thing that turns users away is learning the magic.