On Wed, Oct 14, 2009 at 11:00 PM, Christian Oudard
wrote:
>
> I'm a bit green on doing documentation, but I'll give it a try. I'll
> probably have to post a documentation patch and get some feedback a
> few times before it's correct. Should I mark it as changed in version
> 1.2 like this?
>
> ..
I'm a bit green on doing documentation, but I'll give it a try. I'll
probably have to post a documentation patch and get some feedback a
few times before it's correct. Should I mark it as changed in version
1.2 like this?
.. versionchanged:: 1.2
On Oct 12, 7:36 pm, Russell Keith-Magee
wrote:
On Tue, Oct 13, 2009 at 12:29 AM, Christian Oudard
wrote:
>
> I think using it as a prefix is a good solution. Updated the patch,
> and attached it to the ticket. Should we reopen the ticket?
Done. I've also marked it for v1.2 so I remember to check it in.
All that is missing now is some docume
I think using it as a prefix is a good solution. Updated the patch,
and attached it to the ticket. Should we reopen the ticket?
On Oct 12, 11:36 am, Wes Winham wrote:
> I love the prefix idea. Seems like the best of both worlds. I also
> agree that changing the name to either ``prefix`` or ``msg
I love the prefix idea. Seems like the best of both worlds. I also
agree that changing the name to either ``prefix`` or ``msg_prefix``
would probably be preferable, to explicitly indicate that the behavior
is different than the standard msg argument.
This would certainly satisfy my use case.
-we
>
>
> > def assertFormError(self, response, form, field, errors, msg=None):
> >...
> >self.fail(msg or "The field '%s' on form '%s' in context %d"
> > " contains no errors" % (field, form, i))
>
> would become:
>
> prefix = msg and "%s: " % msg or ""
> self.
On Sat, Oct 10, 2009 at 8:21 PM, Russell Keith-Magee wrote:
> One thought that has occurred to me is that rather than using msg as
> the complete literal error string, we could use it as a prefix to the
> literal.
>
> i.e., to take line 124 that you used as an example:
>
> > def assertFormError(s
On Sat, Oct 10, 2009 at 1:16 AM, Christian Oudard
wrote:
>
> First off, thank you all for responding and discussing this issue.
>
> Responding to Russell's comments on the quality of the patch, I agree
> that it needs better test coverage. I've uploaded an updated patch
> which covers all exit po
First off, thank you all for responding and discussing this issue.
Responding to Russell's comments on the quality of the patch, I agree
that it needs better test coverage. I've uploaded an updated patch
which covers all exit points of assertFormError. The better tests
confirm that the original p
On Thu, Oct 8, 2009 at 11:58 AM, Wes Winham wrote:
> This gives me a nice little summary. I know that there were more foo's
> displayed on the page than there should have been.
I second that. The option to specify a quick message explaining what
the failure means, for anyone who didn't write th
I haven't looked at the proposed patch, but I'd like very much to be
able to add a ``msg`` argument to assertContains and assertRedirects
at least. The point of the msg argument in normal asserts is to give
the person running the tests a quick, high-level indication of what
went wrong or what was
On Wed, Oct 7, 2009 at 11:15 PM, Christian Oudard
wrote:
>
> I wanted to get some feedback from the mailing list about a patch I
> wrote. There are two approaches I tried, and attached them both to
> this ticket:
>
> http://code.djangoproject.com/ticket/10314
>
> Quick explanation: Basically, the
I wanted to get some feedback from the mailing list about a patch I
wrote. There are two approaches I tried, and attached them both to
this ticket:
http://code.djangoproject.com/ticket/10314
Quick explanation: Basically, the assertFoo methods in the python
stdlib test case class accept a "msg" p
13 matches
Mail list logo
