Re: Building a library of SQL functions into Django

2014-07-02 Thread Anssi Kääriäinen
On Wed, 2014-07-02 at 08:56 +0300, Anssi Kääriäinen wrote: > The overhead is likely small, but it is hard to know without > benchmarking. The WhereNode instances go through compiler.compile(), so > generating SQL for qs.filter(*lots_of_args) should tell pretty well how > much overhead there is. Th

Re: Response Fixes

2014-07-02 Thread Aymeric Augustin
I find it wrong to alter the response created by the developer unconditionally and not provide any escape hatch. Therefore option 1 is my favorite. I'm proposing to documenting the backwards incompatibility in the release notes. It will only affect project that do not use CommonMiddleware. There a

Re: Response Fixes

2014-07-02 Thread Łukasz Rekucki
On Jul 2, 2014 2:09 PM, "Aymeric Augustin" < aymeric.augus...@polytechnique.org> wrote: > > I find it wrong to alter the response created by the developer unconditionally and not provide any escape hatch. It doesn't just alter it, but makes it conform to HTTP standard. While most browsers will acc

Re: Response Fixes

2014-07-02 Thread Florian Apolloner
On Wednesday, July 2, 2014 3:36:22 PM UTC+2, Łukasz Rekucki wrote: > > It doesn't just alter it, but makes it conform to HTTP standard. While > most browsers will accept relative urls, I don't think Django should > sacrafice backwards compatibility for an arcane CGI feature. Internal redirects

Re: collectstatic - override default ignore list

2014-07-02 Thread Tomas Ehrlich
Hi, thank you for review. I'm just a bit confused with final decision. As Jannis commented on ticket: "This is simple, don't add a global setting but a parameter to the staticfiles app config. That's where such things belong now." But according to Aymeric, app config isn't ready for custom set

Re: Response Fixes

2014-07-02 Thread Aymeric Augustin
2014-07-02 15:36 GMT+02:00 Łukasz Rekucki : It doesn't just alter it, but makes it conform to HTTP standard. As usual, given a different set of expectations, auto-fix is auto-break. We recently removed two of the four unconditional response "fixes". The remaining ones are: - `fix_location_hea

Re: collectstatic - override default ignore list

2014-07-02 Thread Aymeric Augustin
2014-07-02 17:21 GMT+02:00 Tomas Ehrlich : > I'm just a bit confused with final decision. > I don't think we have a decision yet ;-) > As Jannis commented on ticket: "This is simple, don't add a global setting > but a parameter to the staticfiles app config. That's where such things > belong no

Re: collectstatic - override default ignore list

2014-07-02 Thread Jannis Leidel
On 02.07.2014, at 21:17, Aymeric Augustin wrote: > 2014-07-02 17:21 GMT+02:00 Tomas Ehrlich : > I'm just a bit confused with final decision. > > I don't think we have a decision yet ;-) > > As Jannis commented on ticket: "This is simple, don't add a global setting > but a parameter to the s

Re: collectstatic - override default ignore list

2014-07-02 Thread Tomas Ehrlich
Dne Wed, 2 Jul 2014 21:17:52 +0200 Aymeric Augustin napsal(a): > 2014-07-02 17:21 GMT+02:00 Tomas Ehrlich : > > > I'm just a bit confused with final decision. > > > > I don't think we have a decision yet ;-) Tim Graham made comment on PR: "Closing for now as the consensus seems to be adding a

Re: collectstatic - override default ignore list

2014-07-02 Thread Andre Terra
On Wed, Jul 2, 2014 at 5:14 PM, Tomas Ehrlich wrote: > I would really like to see app configs with app-specific settings. > Personally, I don't like flat settings where namespaces are created > with prefixes (eg. STATICFILES_ ). > > The idea of overriding class attributes in AppConfig seems promi

Re: Response Fixes

2014-07-02 Thread Łukasz Rekucki
On 2 July 2014 15:42, Florian Apolloner wrote: > On Wednesday, July 2, 2014 3:36:22 PM UTC+2, Łukasz Rekucki wrote: >> >> It doesn't just alter it, but makes it conform to HTTP standard. While >> most browsers will accept relative urls, I don't think Django should >> sacrafice backwards compatibil

Re: Regression in ValidationError in 1.7

2014-07-02 Thread Carl Meyer
On 06/27/2014 06:41 AM, Russell Keith-Magee wrote: > > On Fri, Jun 27, 2014 at 7:35 PM, Curtis Maloney > mailto:cur...@acommoncreative.com>> wrote: > > Am I reading this right as "people used to commonly solve this > problem by using an internal API, but now we have a public one... >

Re: Response Fixes

2014-07-02 Thread Łukasz Rekucki
On 2 July 2014 21:14, Aymeric Augustin wrote: > 2014-07-02 15:36 GMT+02:00 Łukasz Rekucki : > >> It doesn't just alter it, but makes it conform to HTTP standard. > > > As usual, given a different set of expectations, auto-fix is auto-break. > > We recently removed two of the four unconditional res

Re: Regression in ValidationError in 1.7

2014-07-02 Thread Russell Keith-Magee
Hi Carl, On Thu, Jul 3, 2014 at 5:33 AM, Carl Meyer wrote: > On 06/27/2014 06:41 AM, Russell Keith-Magee wrote: > > > > On Fri, Jun 27, 2014 at 7:35 PM, Curtis Maloney > > mailto:cur...@acommoncreative.com>> wrote: > > > > Am I reading this right as "people used to commonly solve this > >

Re: collectstatic - override default ignore list

2014-07-02 Thread Curtis Maloney
OT...just writing down this which came to me on the train this morning as I read this thread Does anyone else foresee the practice of having an "appconfig.py" full of subclasses of AppConfigs becoming common? Seems like a nice parallel to settings, allowing a project to specify per-app config ov

modelformset_factory and unique_together don't always validate unique fields

2014-07-02 Thread Jon Dufresne
I'm reporting this to the developers list as I feel this shows a shortfall in (to me) expected behavior. I'm not sure this is exactly a bug or simply a use case the unique validation wasn't designed for. Basically, sometimes I want to create model formsets that use a limited number of model fields

Re: collectstatic - override default ignore list

2014-07-02 Thread Aymeric Augustin
On 2 juil. 2014, at 22:14, Tomas Ehrlich wrote: > The idea of overriding class attributes in AppConfig seems promising. My concern -- and the reason why I started talking about an API -- is, if every app clutters the AppConfig namespace with arbitrary names, improvements to AppConfig may create