Re: Google Organic Search Results for Documentation

I think this is somewhat ameliorated by being able to link to the current trunk documents these days. Many incoming links will be going there. Additionally, for old documents, there is the "these docs are old" message at the top. It might be beneficial to make that easier to see for a user who

Django 1.3 and Python 2.4

Django 1.2 dropped support for Python 2.3. In the past, there has been talk of dropping a version of Python per Django release. Python 2.4 is relatively rare these days, but still supported by RHEL. None of us like coding for it, and I know that several of the core devs have voiced support in IRC

Re: #717 (If-Modified-Since checked for exact match) should be fixed

I agree with the person who closed the ticket again, since this should have been discussed on the mailing list prior to re-opening it. That said, I'm strongly +1 on this issue. I've had to write workarounds for exactly the described behavior on other systems, and it hasn't been good. Django

Re: Admin - Selector Inlines in 1.3?

That would be a rather nice feature. +1 On Thu, Jul 15, 2010 at 2:21 AM, andybak wrote: > Hi, > > As far as I know this is the only major chunk of Zain's SOC work that > didn't make it into 1.2 > > There's a ticket for it: http://code.djangoproject.com/ticket/12509 > that's

test refactor update

This past week I've been working on integrating unittest2. There were several difficulties including precisely how to bundle it (yes, we're doing that, I know, many of us don't like the choice), and I ended up needing to bundle a patched version because of the format used by the imports in the

test-refactor update

I've been ill, hence the late update and lack of progress. Last week I only committed 2 test updates, but spent significant time tracking down a fix for #13821 since it was preventing existing tests from running on Postgres 8.3. -Paul -- You received this message because you are subscribed to

Re: Proposal/RFC: assertContextContains

A very minor note, but... On Jun 24, 1:31 am, JK Laiho wrote: > self.assert_('varname' in response.context) Please use self.assertTrue(). assert_() is deprecated in unittest2. http://www.voidspace.org.uk/python/articles/unittest2.shtml#deprecations -Paul -- You received this

Re: test-refactor update

> Firstly, do you have any evidence that this goal is achievable? If > you've converted 7 this week, what makes you think you will be able to > convert 25 next week -- especially when there are tests like > regressiontests/queries still out there? Can you provide stats in > terms of LOC converted,

test-refactor update

I've posted an update with my project status. I made a little progress this week, converting 7 model tests. In order to meet my goals for finishing the project, I plan to be converting 25 directories a week moving forward. http://thefire.us/archives/450 -Paul -- You received this message

testing-update GSOC status

Since it wasn't readily apparent, I've been posting updates about my progress to my personal blog. The updates can be found here: http://thefire.us/archives/tag/gsoc2010 The short summary is that things are going slowly, but that I plan to pick up the pace significantly. I'll post notes to -dev

including unittest2 in 1.3

There has been some discussion of unittest2 before on the list, and there's a ticket about including it. http://code.djangoproject.com/ticket/12991 We get a bunch of useful features with unittest2, and everyone I've spoken with on #django-dev agrees that it would be a useful thing to get into

Re: Decision required: PostgreSQL minimum versions

+1 for option 2. Changing 1.2 behavior now seems like a bad idea, and Jacob's arguments are good. -Paul On Jun 9, 10:22 am, Felipe Prenholato wrote: > +1 for options 1 and 2. > > I think that change for 1.2.x is to close and we probably have some users > that not want

Re: Long-running tests

I'm hoping to be able to help with this problem during the SoC. In particular, I'm hoping that we can integrate unittest2 to make skipping these long-running tests easier. > And I know why. There are 10 of these: > >>> management.call_command('flush', verbosity=0, interactive=False) > for

Re: Application to update the Test Suite

Wow... lots of stuff here. > >> This is > >> because SQLite uses an in-memory store, so it isn't disk bound; > >> Postgres is disk bound, but is able to use transactions to optimize > >> test setup and teardown; MySQL is also disk bound, but doesn't support > >> transactions, so there are a lot

Re: Application to update the Test Suite

I've revised the proposal, but am inlining more complete answers. > If someone needs to fix a bug, they will essentially need to > write the test twice; once for the old framework, and once for the > new. Do you have any suggestions on what we should be doing to > mitigate this complexity?

[GSOC] Application to update the Test Suite

I've written an application to improve Django's Test Suite. http://code.djangoproject.com/wiki/SummerOfCode2010#Testingupdates My application is here (also pasted below for convenience): http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/paulmcmillan/t127077396156 I'm hoping

<    1   2