Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

Personally I'd be in favour of adding such classes. It seems against the batteries-included philosophy that Django does not provide all of the standard codes as classes. I can never remember which codes correspond to which response types, if I saw status=204 in code it would be a 'magic number' for

Re: DJANGO_SETTINGS_FILE

There are indeed a nice handful of apps out there that help doing this in different manners. While we're at it, my own way is to make every project a python package with a setup.py. So the settings can always be imported. Then I let docker swarm or kubernetes handle environment variables which are

Paginator Class - Refactor page function for better abstraction

So the existing Paginator class is great for the standard use case. But recently I wanted to be have a Paginator that would return *at least per_page *x items. I called it FlexPaginator. My use case was that I had a group_by value that I wanted to keep together on the same page, and so the row

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

I think you'd better write the decision in the document to stop Django users from making the same feature request in future ! On Thursday, April 6, 2017 at 12:35:41 AM UTC+8, Tim Graham wrote: > > Hi, this was already wontfixed here: > https://code.djangoproject.com/ticket/3362 > > with the ratio

Re: DJANGO_SETTINGS_FILE

Look through https://code.djangoproject.com/wiki/SplitSettings for many different approaches to loading settings from files that aren't importable as Python modules. My personal favorite is django-split-settings, which would let you accomplish exactly what you're trying to do. On Thu, Apr 6, 201

Re: DJANGO_SETTINGS_FILE

I don't see Django making a change like this. If it's really impossible to get your production settings file on an already-importable Python path, you *could* modify your PYTHONPATH environment variable to add the directory containing

Re: DJANGO_SETTINGS_FILE

You could do this already by putting a file on PYTHONPATH that just reads the contents of the file specified by DJANGO_SETTINGS_FILE and puts it in its own module dict, e.g. $ cat ~/tmp/test.py foobar = 12 $ TEST_SETTINGS_FILE=~/tmp/test.py ipython ... In [1]: import imp, os In [2]: test = imp.l

Re: Django 1.8 - django 1.7 differences to read DecimalField

Hi Tim, Thanks for the tip. I finally found the problem [1], which was obviously between the chair and the keyboard. Regards. Maxi [1] https://github.com/maxirobaina/django-firebird/issues/69 El miércoles, 5 de abril de 2017, 20:27:11 (UTC-3), Tim Graham escribió: > > I'd suggest to use git

DJANGO_SETTINGS_FILE

Hi all! Life with DJANGO_SETTINGS_MODULE has been great. However, it requires the settings to be an importable module. In most cases, this is a straight forward "simple" python script. Sometimes it looks like it could make sense to add an environment variable that could use a file that is not imp

Re: Adding generated common table expressions

On Thursday, April 6, 2017 at 11:53:32 AM UTC+3, Marc Tamlyn wrote: > > Regarding Anssi's comments about SubQuery, we do now have that in core as > of 1.11 [0]. It does look like an .attach() approach might actually have > been a nicer version of this, but on the other hand it's currently > impl

Re: Adding generated common table expressions

Oh right, I feel silly for not thinking of named arguments as a resolution there, that's a damn good idea! It resolves a couple of minor issues I'd anticipated in a complete implementation, so consider the idea stolen! ;) I mean, ummm, that was totally what I had planned! - Ashley On 06/04/201

Re: Adding generated common table expressions

Hi! This looks generally very good, and I'm quite excited about it. In terms of taking it forwards, I think a DEP is a very good idea, and there are at least 3 core devs who are keen to see a solution. Whether you have the right solution yet I'm not so sure, but it sounds like you're not either.