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

While mucking with the refactoring of adodbapi, I included a patch fixing a bug when storing data into columns of type "adGUID". I had not been really aware that SQL Server has a dedicated data type for UUID until that ticket surfaced. Then I started thinking about the column in one of my CDC

Re: Request method in urls.py

On 13 kwi 2013, at 23:48, Brantley Harris wrote: > It would be extremely easy to implement Such a statement suggests that the you didn't really think the problem through. Few things are "extremely easy to implement", especially in a framework with years of legacy

Re: Request method in urls.py

On Sun, Apr 14, 2013 at 4:56 AM, Łukasz Langa wrote: > On 13 kwi 2013, at 23:48, Brantley Harris wrote: > > > It would be extremely easy to implement > > Such a statement suggests that the you didn't really think the problem > through. Few things are

Re: Request method in urls.py

On 13/04/13 22:48, Brantley Harris wrote: > There's a line in the django URL Dispatcher documentation that is pretty > weird: > > The URLconf doesn’t look at the request method. In other words, all > request methods – POST, GET, HEAD, etc. – will be routed to the same > function for

Re: Request method in urls.py

On Sun, Apr 14, 2013 at 2:40 PM, Luke Plant wrote: > One reason for not doing this kind of despatch is that handling for > different HTTP methods often involves a lot of common code. The classic > form workflow would become longer, more complicated and/or less DRY if > it

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

On Sun, Apr 14, 2013 at 7:03 PM, VernonCole wrote: > While mucking with the refactoring of adodbapi, I included a patch fixing > a bug when storing data into columns of type "adGUID". I had not been > really aware that SQL Server has a dedicated data type for UUID until

[GSoC 2013] Improving code quality

Hi, After looking through proposed ideas for the current GSoC i found 2 issues related close to the code quality which I'm interested in. These are: 1. Best practices Updates 2. Improved error reporting Both tasks are a different but they are very closely related just to code

Re: [GSoC 2013] Improving code quality

On Mon, Apr 15, 2013 at 7:51 AM, Damian Skrodzki wrote: > Hi, > > After looking through proposed ideas for the current GSoC i found 2 issues > related close to the code quality which I'm interested in. These are: > > >1. Best practices Updates >2. Improved error

Re: The threat of the incompletely initialized django instance

On Saturday, April 13, 2013 5:03:16 PM UTC-7, Russell Keith-Magee wrote: > > > On Sat, Apr 13, 2013 at 11:53 PM, Pakal > wrote: > >> Hello, >> >> since version 1.2, there has been no changes about this issue, which >> still bothers me: >>

Re: Request method in urls.py

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 Django's url resolver start returning 405s instead of 404s

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

Russ: I am not entirely sure what I am asking, either, but your answer has already helped. Indeed, PEP 249 is silent about support of UUID feilds, because it was written too long ago. It is also silent about support of decimal and datetime fields for the same reason. You have just taught