Re: Request method in urls.py

On Mon, Apr 15, 2013 at 6:32 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On Tue, Apr 16, 2013 at 6:12 AM, Brantley Harris wrote: > >> Alex, I see http methods as being very basic, a part of the URL itself. >> In other words, from the level of the web

django-localflavor-* issue tracker clarifications

It's unclear whether issues for the django-localflavor-* repositories should be submitted on Github or via the main Trac issue tracker. I think this should be clarified in the README file for each django-localflavor-* repository. There has been an open issue on the django-localflavor-us package

Re: Request method in urls.py

On Tue, Apr 16, 2013 at 6:12 AM, Brantley Harris wrote: > Alex, I see http methods as being very basic, a part of the URL itself. > In other words, from the level of the web framework it's pointless to talk > about the URL as anything but a pair of request method and path.

Re: [GSoC 2013] Improving code quality

Yes - I was referring to error reporting. Although the same would be true for 'best practices'. Yours, Russ Magee %-) On Mon, Apr 15, 2013 at 3:22 PM, Damian Skrodzki wrote: > Thanks for the answer. > > Just to be sure. As "Take the first project" you mean "2. Improved

Re: Request method in urls.py

Alex, I see http methods as being very basic, a part of the URL itself. In other words, from the level of the web framework it's pointless to talk about the URL as anything but a pair of request method and path. Strangely, I'm not sure I agree with you that intelligent dispatch decisions

Re: Request method in urls.py

On Mon, Apr 15, 2013 at 1:22 PM, Donald Stufft wrote: > > On Apr 15, 2013, at 1:16 PM, Alex Ogier wrote: > > The problem I have with fallthrough-based dispatch is that it encourages > really expensive performance-killing patterns, where you end up doing a

Re: Request method in urls.py

On Apr 15, 2013, at 1:16 PM, Alex Ogier wrote: > The problem I have with fallthrough-based dispatch is that it encourages > really expensive performance-killing patterns, where you end up doing a > linear scan over view functions round-tripping to the database for each

Re: Request method in urls.py

The problem I have with fallthrough-based dispatch is that it encourages really expensive performance-killing patterns, where you end up doing a linear scan over view functions round-tripping to the database for each one to see if the view can handle the request. multiurl is sort of nice because

Re: survey question: should UUID database fields be returned as instances of class "uuid"? (re: ticket 19463)

On Mon, Apr 15, 2013 at 1:51 AM, VernonCole wrote: > So -- is it worth my time to muck with direct database api support of uuid > fields? > Add the support. Each database backend defines the mapping for the core model field types (see DatabaseCreation.data_types) and any

Re: Request method in urls.py

This proposal is actually *very* similar to the 'URL dispatcher fall-though' threadthat came up recently. I don't think it'd take much adjustment to take Jacob's django-multiurl project

Re: The threat of the incompletely initialized django instance

(my previous answer disappeared in googlemail, I hope that one will survive the sending...) Thanks for the feedback, Preston, since ticket #3591 ticket and related discusions are partially obsolete compared to your current works, may I just know if your current evolution will automatically

Re: Request method in urls.py

On 15/04/13 10:21, Aymeric Augustin wrote: > Django already has a syntax for that : > > from django.conf.urls import * > from django.views.decorators.http import * > > urlpatterns = patterns('', > url(require_GET(view_that_only_accepts_get), name='accept-get'), >

Re: Request method in urls.py

On 15 kwi 2013, at 11:21, Aymeric Augustin wrote: > Not every feature has to be supported via keyword arguments in the URLconf. > Many are expressed through decorators. > > The URL dispatcher might have been designed differently in the first place, > but

Re: Request method in urls.py

2013/4/15 Alex Ogier > I agree, I think there are use cases for both types of dispatch, and it > seems clean and well-defined to make a route that is valid for only a > subset of HTTP methods. I guess there are a few corner cases to think > about, for example should

Re: [GSoC 2013] Improving code quality

Thanks for the answer. Just to be sure. As "Take the first project" you mean "2. Improved error reporting", correct? I wrote the whole post in reversed order which could confuse you. On Monday, April 15, 2013 2:18:56 AM UTC+2, Russell Keith-Magee wrote: > > > > On Mon, Apr 15, 2013 at 7:51 AM,