Re: Consistent ordering of database Booleans

I thought I'd responded to that ticket with a similar suggestion but I must have clicked away before submitting. Yes, providing a transform would be ideal. Unfortunately order_by does not support __lookup syntax. Adding __lookup syntax support to F() is tracked here

Re: is_authenticated as property

I agree with the ticket. The imbalance between is_superuser and is_authenticated() should be enough to consider updating the API. The security concerns and, in particular, Aymeric's Jinja example, make this ticket more compelling. I think we should be asking.. why not? If there's not a good

Re: worth adding PyPy to continuous integration?

Shouldn't we decide if we want to support pypy first? By putting it on CI that's an implicit agreement to support pypy potentially at the cost of certain features. There's also the consideration that python2 is going away in django 2.0, so if pypy3 isn't up to date wrt python3, we'd have to

Consistent ordering of database Booleans

Hi, A ticket[1] that was wontfix'd almost three years ago says, """ When using a model with a boolean field, you can retreive a QuerySet and order it on the boolean field. In Postgres, the true comes first, in SQLite, false comes first. """ The reason to wontfix was that this difference

Re: Migration "rebase", or just an "undo" that works with conflicts

As long as whatever tool we have fails hard rather than doing weird things with related dependencies, I'm in favour of automating the process more - we should reduce friction around migrations wherever possible. As for undoing a conflicted migration, it should be relatively simple to make the

Re: Migration "rebase", or just an "undo" that works with conflicts

On Tuesday 01 December 2015 08:40:34 Andrew Godwin wrote: > You can undo a migration manually using migrate, though if you're in > multiple-tip-migration scenario you may need to make a merge migration > first (but not apply it) or switch to a branch with only the migration you > wish to undo. >

Re: annoyance with Python 3.2 support in Django 1.8

On Wednesday 02 December 2015 21:05:00 Tim Graham wrote: > > Given that no one reading this indicated that they plan a long-term > deployment of Python 3.2, how about if in the next 1.8.x release we > advertise that Python 3.2 support for Django 1.8 will end January 1, 2017? > (we won't break

Re: is_authenticated as property

On Wednesday 02 December 2015 18:51:03 Aymeric Augustin wrote: > > We could implement a property that returns an object: > > - that is still callable, for backwards compatibility > - that evaluates correctly in a boolean context > > Then we can consider deprecating the ability to call it. > >

Re: __ne, #5763

Dear Anssi, Am 2015-11-22 um 13:53 schrieb Anssi Kääriäinen: The author_count name suggested this was an aggregation. If this is just a regular field, then things are a bit simpler. Note that negated Q-object + filter and exclude() queries are the same thing. [...] There is a fix for exactly

Re: annoyance with Python 3.2 support in Django 1.8

I ran into another snag trying to put the Python 3.2 tests on the 14.04 machines and that's that the unittest-xml-reporting package we use on Jenkins to collect the test results isn't compatible with Python 3.2 (the Ubuntu 12.04 machine uses an older fork of unittest-xml-reporting but I

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

Seems to me we could ignore the referrer if we get a valid same-domain Origin header. On Wed, Dec 2, 2015 at 1:29 PM, Flávio Junior wrote: > Some browsers already implement the Referrer Policy draft >

Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

Some browsers already implement the Referrer Policy draft , which gives the developer more control over the referer HTTP header sent by the browser. Sometimes is useful to set a more private policy, like *Origin When

Re: worth adding PyPy to continuous integration?

If we can get it running on the CI reasonably easily I see no reason why not. On 2 December 2015 at 16:46, Tim Graham wrote: > Once in a while, we get a ticket about failures when running the Django > test suite on PyPy. Sometimes they are bugs in PyPy, other times we use

Re: is_authenticated as property

Django 1.8 worsens the situation significantly: {% if request.user.is_authenticated %} does the right thing in a Django template but is a security vulnerability in a Jinja2 template! We could implement a property that returns an object: - that is still callable, for backwards compatibility

worth adding PyPy to continuous integration?

Once in a while, we get a ticket about failures when running the Django test suite on PyPy. Sometimes they are bugs in PyPy, other times we use something that's not available or behaves differently in PyPy. Is it worth adding PyPy to our continuous integration so we can proactively address

Re: is_authenticated as property

On a somewhat unrelated note, is_authenticated really only makes sense when using request.user.is_authenticated. If you simply query a user from the database, is_authenticated will be True, which doesn't make any sense outside the context of a request. is_anonymous makes sense, is_authenticated

Re: is_authenticated as property

> My own opinion is that if you don't have tests to catch the mistake in the first place, you're doing it wrong. Not sure I'd necessarily agree there - easy to miss the anonymous case. No obvious best thing to do tho'. On the one hand it's too easy to get wrong, on the other the current visual

Re: is_authenticated as property

Someone created a ticket to raise this issue again. I found several improper usages with GitHub code search. Is there any support for the idea or would it be too much magic? My own opinion is that if you don't have tests to catch the mistake in the first place, you're doing it wrong.