Re: Merge policy for cleanup commits

> I can't speak for other core devs, but I won't merge such PRs for a very > simple reason: it's more tedious and time-consuming to review them than to > redo them by myself. Even though there are many changes, the changes are very obvious and simple and quick to review. > If someone took

Re: Tests -- Errors vs. Failures

I'm in favor of the second version because the first one hides the stack trace. `self.fail` is almost always the wrong answer, because the actual failure happened earlier in the test! I usually include a comment like "# this should not raise an exception" in such tests to explain why they

Re: Tests -- Errors vs. Failures

Hi Shai, On 07/08/2013 02:55 PM, Shai Berger wrote: > I just pushed a fix to a test failure on Oracle -- the last-executed-query > test. However, I want to ask about the preferred style in writing the test > itself. The test, as it is written now, is: > > def

Tests -- Errors vs. Failures

Hi all, I just pushed a fix to a test failure on Oracle -- the last-executed-query test. However, I want to ask about the preferred style in writing the test itself. The test, as it is written now, is: def test_last_executed_query(self): """ last_executed_query should not

Re: Merge policy for cleanup commits

I have to agree with Aymeric, despite being one of those people who wanted to fix this at times in the past. It is worth remembering that some areas of the Django code base are very old, and python coding standards in the community were not as strong when the code was written. Believe it or not,

Re: Merge policy for cleanup commits

On 8 juil. 2013, at 18:59, Danilo Bargen wrote: > While I agree that small PRs which fix issues like whitespace should not > necessarily clutter up the commit history, I disagree for larger cleanup > commits. In some places the code has serious formatting issues (e.g. lines

Merge policy for cleanup commits

Hi there (I tried to find previous threads concerning the same topic, but could not find any. If this is already the n-th discussion about the topic, sorry about it.) I don't quite agree with the cleanup commit policy stated in the docs: Systematically remove all trailing whitespaces from

Proposal of new feature: handler to HttpResponseNotAllowed (status 405)

Django allowsusers to define handlers to some exceptions, most notably http404, server error (status 500) and permission denied (status 403). I here propose this feature to be extended to

Re: Reconsider 20383: limited contexts for makemessages

On 05.07.2013, at 13:57, Ned Batchelder wrote: > On 7/4/2013 5:40 AM, Benjamin Wohlwend wrote: >> Hi, >> >> I recently hit a problem where I have to provide translations for a reusable >> app. In German (and most other languages, except English, it seems), there >>