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
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
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
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
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
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
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
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
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
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
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
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...
>
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
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
> >
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
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
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
17 matches
Mail list logo
