Re: integrating django-secure

> Le 28 août 2014 à 03:25, Tim Graham a écrit : > > I am fine with putting it in core instead of contrib. That just means we need > to figure out what to do about settings since we cannot put them on an > AppConfig. Assuming we don't want to add them as normal settings,

Re: integrating django-secure

After I wrote the original email, I found #17101 which is where the checkdeploy idea came from. We can just close that ticket (or modify it) if we decide on a different solution. It was created before the checks framework was merged and I agree a

Re: integrating django-secure

For what it's worth, I agree with Russ. Having security as an optional extra [which is how it will look to outsiders] is a bad look for Django, and certainly doesn't fit with the "Secure by default" philosophy. -- Curtis On 28 August 2014 10:34, Russell Keith-Magee

Re: integrating django-secure

Hi Tim, On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham wrote: > I've started tackling one of the ideas that's been on our GSoC ideas > page for a couple years now: integrating django-secure. I chatted with > Carl about the idea and he's onboard. There are a couple of design >

Re: Improvement to objects.get_or_create and objects.update_or_create

I don't believe the functionality is backwards incompatible at all unless I'm missing something. The new behavior of automatically selecting the optimal search field (prioritized by pk first then by any discovered field marked as unique) would only occur if the 'default' parameter was None. Then,

Re: Improvement to objects.get_or_create and objects.update_or_create

This would be fairly significantly backwards incompatible, and any heuristic based code I think belongs in user space. It should not be too problematic to write as an external module, if it gains a lot of traction we can reconsider. Worth also noting that the json implementation in

Fwd: Improvement to objects.get_or_create and objects.update_or_create

Apologies for the cross-post. I imagine this is actually where this proposal belongs. Would anyone be interested in getting an implementation of this for consideration for incorporation into some upcoming or back ported release of Django? -- Ben Scherrey -- Forwarded message --

integrating django-secure

I've started tackling one of the ideas that's been on our GSoC ideas page for a couple years now: integrating django-secure. I chatted with Carl about the idea and he's onboard. There are a couple of design decisions we'll need to make. 1. How to integrate django-secure with the checks framework

Re: Cleaning up broken pipe errors in runserver

I'm +1 for this, for the same reasons; I have a monkey patch for my selenium tests which does the same thing as this PR. On Saturday, 2 August 2014 18:20:18 UTC-6, Matthew Somerville wrote: > > Hi, > > I have created a branch at > https://github.com/dracos/django/compare/pipe-cleaning that

Re: Fields terminology for official Options API

I was also thinking of MetaModels or something instead of Options, as I think it makes it more obvious what it's for. On Friday, 1 August 2014 00:49:41 UTC+2, Josh Smeaton wrote: > > I was thinking "column" fields would make sense but it clashes with the > internal concept of columns (Col