I think the fact that Django's url mapper doesn't make it easy to dispatch based on the method means that Django wouldn't score to highly against this particular issue. It's easy to put

    if request.method not in ('POST', 'PUT', 'DELETE', 'PATCH'):
        ...

at the top of every method (or use a decorator), but it'd definitely be nice if this were part of the url dispatcher.

This is true, but at the same time Django doesn't make it easy to mix up get and post params. Calling request.POST['param'] will raise an exception on a GET request.

Finding rails issues and then saying "they kinda sorta apply to Django" isn't as interesting as finding real Django issues.

request.REQUEST? Admittedly, people don't use it that much, but it's definitely there.

Thanks for this information! Really, it is $_REQUEST as in PHP.

To yummyfajitas - your message is 50% trolling. Will you allow me to troll a little bit? I used django and scrapy few years ago and despite the fact it was better than PHP I would not even dare to compare it with Rails. Rails is that superior I don't even have words to explain it :D Conclusion: I'm not interested in Django and its bug because I love rails and wanna make it more secure anyways. Sorry, but Django is way less convinient to use. Security is another story though.

Sorry, I didn't intend to sound like I was trolling, my comment "I'm feeling very superior" was intended to be facetious.

Also, if you ever manage to put into words why you prefer Rails, I'd love to read it. Django and rails seem pretty similar to me, but I didn't put much effort into learning rails. But maybe I'm just experiencing the blub paradox.

So I don't think yummyfajitas was trolling, but he obviously likes Django. Like him, I like Django as well, but I happen to think that a healthy criticism of any popular framework is worthwhile. I think it's telling that AFAIK all more recent python frameworks bake in method dispatching to the url dispatcher.

It's not in the URL dispatcher in Django, but the class based views have separate methods that are called depending on the HTTP verb such as get(), post() etc.

It was a problem with the older function based views, and there was a lot of boilerplate to ensure the correct HTTP verb was being used.

When using class-based views, this is already built in. You can do something this:

    from django.views.generic.base import View
    from django.http import HttpResponse
    
    class MyView(View):
        def get(self, request):
            return HttpResponse("Get request")

        def post(self, request):
            return HttpResponse("Post Request")

The functionality to make this "just work" (dispatch based on method) is built into django.views.generic.base.View.dispatch.