Hi Rach -- Thanks for the clarification. I'd like to make three broader points. They may not seem like they're directly addressing your proposal, but stick with me, I promise this comes together to your specific proposal at the end:
1. "But framework X does it like this" isn't a particularly good argument for why *Django* should do something. Yes, it's important to understand and follow what's going on in the greater web world, and yes it's important to beg, borrow, and steal good ideas. But you have to articulate why an idea is *good for Django*. After all, if we wanted to be just like Framework X, we'd all just be using Framework X. In many ways the high quality of our competitors actually frees us up to be *more* skeptical of what we add to Django. We don't *need* to be more like other frameworks because those other frameworks are usually *great* -- if you like them, you should use them! We should be focusing on doing the things we're good at. Let Django be Django. 2. One of the really high bars you have to clear when you propose new things for Django is the bar of utility. It's not good enough to demonstrate that something's a good idea. It's not good enough to demonstrate that it solves your problem. It's not even good enough to demonstrate that it solves some bigger problem. You have to demonstrate that what you're proposing is so useful that a sizable portion of people using Django would be excited by your new thing. One of Django's real strengths is its stability, but the cost of that strength is that we say "no" a lot. 3. Flexibility is a very important goal. Our philosophy of "sensible defaults" doesn't mean that the default choice should be the only choice! It means that we should provide a reasonable default for most people, but then give people "escape hatches" when those defaults don't quite work out. So given these principles, let's look at your proposal again: 1. Much of your argument seems to come down to "Pyramid does it this way." It does, and it's a good match… for Pyramid. You haven't articulated why this is a good addition *for Django*, and I think that's because it isn't. Django's @require_POST and friends are simple, obvious, and easy to understand, whereas this predicate business adds another layer of complexity. Further, it violates one of the cardinal design points of the routing system, which is that all the information you need to figure out routing should be in the routes file. Pushing routing logic down into the views -- which is what your proposal does -- violates this basic tenant of Django. That design is pretty close to set in stone; you're going to need a very excellent argument to change a design choice that's been in place for nearly a decade now. 2. One of the ways you might win that argument would be by arguing massive utility for a large segment of Django's user base. Again, though, we already have this feature implemented in a more "Django-esque" way, so I don't really buy that argument. 3. Ah, but there is something deeper here worth looking at. URL routing is one of the *least* flexible parts of Django. It's possible to customize routing (see https://github.com/jacobian/django-multiurl for one example), but it's rather complicated and relies on a pretty deep understanding of how routing works. That's bad; it should be easier to add these sorts of things if you choose *without* needing to add something new to Django. So, let's bring it all together: What you're proposing -- view predicates -- isn't going to happen. You're welcome to keep tilting at this windmill, but the chances of this making it into Django proper are essentially nil. However, if you're willing to take a step back from your specific problem, there *is* something worth looking at here: making routing, in general, something that's easier to swap out. So the path forward for you, if you're willing to rise to the challenge, involves figuring out how to make routing more flexible to the point that what you want to implement is doable as a trivial third-party package. Jacob On Wed, May 22, 2013 at 6:13 PM, Rach Belaid <[email protected]> wrote: > Thanks for the feedback. > > I assume If it's not use then performance should be the same. > But I don't know if the single check for the presence of the attribute or > not would affect much the performance. > > The goal of this feature is offering a hook to allow people extend a bit the > routing logic. > Which is more difficult with Django because routing and view lookup are the > same thing. > > @Sean , I understand your point about have a single view but I hope this > could help people to organize > their function based views in a nice way in the same way that required_GET > could be done inside the view. > > Will be great if you take few min to look how this feature is used in other > framework. > > I'm personally not convince my implementation is the right one but I hope > that could open the discussion > to have a more extensible routing in Django. > > On Wednesday, 22 May 2013 23:21:33 UTC+1, sebleier wrote: >> >> I think what Rach is suggesting is different from @require_GET, >> @require_POST, etc. The patch essentially makes a view invisible if >> the predicate function returns False. >> >> I'm not sure this would be good for inclusion to django, since you are >> tying url resolution to application state . This could have negative >> implications, especially for performance. On top of that, the same >> functionality could be achieved by creating a function/class to route >> the request further after django has initially routed the request. >> This would be preferable because the performance hit would be isolated >> to the resolved routing function/class. >> >> >> >> On Wed, May 22, 2013 at 2:37 PM, Jacob Kaplan-Moss <[email protected]> >> wrote: >> > I'm not sure I understand what you're proposing here. How is this >> > different from @require_GET, @require_POST, and friends? >> > >> > Jacob >> > >> > On Wed, May 22, 2013 at 11:05 AM, Rach Belaid <[email protected]> >> > wrote: >> >> I just did a pull request resulting of my last Django sprints for >> >> adding a new feature in Django. >> >> >> >> https://code.djangoproject.com/ticket/20479 >> >> >> >> The idea is being able to have more control on the url resolving >> >> process. >> >> >> >> I have no merit behind the idea of predicate. Predicate is one of my >> >> favorite feature in Pyramid/Pylons to allow more complex and flexible >> >> routing. >> >> >> >> I will be curious about feebacks? Do you like this idea of features ? >> >> >> >> The implementation is probably imperfect so don't be too harsh ;) we >> >> can always fix the implementation. >> >> >> >> For people unaware about what is a predicate, I advice to check the >> >> pyramid doc here: >> >> >> >> http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewconfig.html#predicate-arguments >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups "Django developers" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> >> an email to [email protected]. >> >> To post to this group, send email to [email protected]. >> >> Visit this group at >> >> http://groups.google.com/group/django-developers?hl=en. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Django developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an email to [email protected]. >> > To post to this group, send email to [email protected]. >> > Visit this group at >> > http://groups.google.com/group/django-developers?hl=en. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
