On 9/11/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
>
> About validate_exception, this is the signature of the corresponding
> method in unittest:
>
> *assertRaises*( exception, callable, *args, **kw)
> they have removed message, but since args and kw will be passed to
> callable, these are the on
On 9/11/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> That said, I'd also recommend that if you're going to draw any
> parallels with unittest assertions, you should probably do it
> reliably. Your validate_exception() example was completely unreadable
> to me, because it works quite differently t
I'll chime in just for a few cents here.
First, I think it's worth noting that most Python programmers find
little value in how many characters they have to type. Sure, Python is
generally less verbose than many other languages, but only to the
extent of making it more readable. So kep readabilit
On 9/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> Well... no. assertEquals exists in Python unittests because
> assertEquals exists in JUnit, and unittest emulates the JUnit API.
> This API is, in turn, based on xUnit, which was derived from SUnit,
> the original Smalltalk implementati
On 9/11/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> On 9/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > I'm afraid you're going to have a hard time convincing me that this is
> > a good idea. I'm willing to entertain the idea of validation helpers
> > if they genuinely add clarity -
On 9/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> I'm afraid you're going to have a hard time convincing me that this is
> a good idea. I'm willing to entertain the idea of validation helpers
> if they genuinely add clarity - but not if they are just a verbose
> replacement for somethi
On 9/11/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> On 9/10/07, Nis Jørgensen <[EMAIL PROTECTED]> wrote:
>
> > I don't like the transformation of strings into field values. How would
> > you compare a field value to a string?
>
> Exactly my reason for not making it a method of BaseForm. If thin
On 9/10/07, Nis Jørgensen <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee skrev:
> > On 9/9/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> >
> >> Python unittest TestCase objects have a lot of helper functions like
> >> assert_(), failUnless(), assertEqual(), assertNotEqual() and so on[1].
> If
Russell Keith-Magee skrev:
> On 9/9/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
>
>> Python unittest TestCase objects have a lot of helper functions like
>> assert_(), failUnless(), assertEqual(), assertNotEqual() and so on[1]. If we
>> had a similar set of helper functions, possibly with more
On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, 2007-09-09 at 21:46 +0800, Russell Keith-Magee wrote:
> > > No - this has nothing to do with the test framework. It's a set of
> > > helper functions to support wri
On 9/9/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Drawback if most of the times we are not using that feature, each validation
> statement will have to contain a superfluous self. in the beginning. Whereas
> helper functions can all be imported in the name space. Its only minor
> syntactic sug
On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-09 at 21:46 +0800, Russell Keith-Magee wrote:
> > No - this has nothing to do with the test framework. It's a set of
> > helper functions to support writing clean_XXX methods.
>
> Okay. Then I'm mostly in agreement, excep
Hi,
since your assert-function won't be like assert in python or UnitTests, you mix
semantics nobody knows everywhere else.
Please remember that assert Statements have special meanings depending on
__DEBUG__
http://docs.python.org/ref/assert.html
http://pyunit.sourceforge.net/pyunit.html#TESTC
On Sun, 2007-09-09 at 21:46 +0800, Russell Keith-Magee wrote:
> On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, 2007-09-09 at 15:58 +0800, Russell Keith-Magee wrote:
> > [...]
> > > - I'm also inclined to continue the similarities, and make the
> > > assertion functions me
On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-09 at 15:58 +0800, Russell Keith-Magee wrote:
> [...]
> > - I'm also inclined to continue the similarities, and make the
> > assertion functions members on BaseForm. This would allow a
> > significant simplification of yo
On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 2007-09-09 at 15:58 +0800, Russell Keith-Magee wrote:
> [...]
> > - I'm also inclined to continue the similarities, and make the
> > assertion functions members on BaseForm. This would allow a
> > significant simplification of y
On Sun, 2007-09-09 at 15:58 +0800, Russell Keith-Magee wrote:
[...]
> - I'm also inclined to continue the similarities, and make the
> assertion functions members on BaseForm. This would allow a
> significant simplification of your proposal, as the data locations
> (i.e., self.cleaned_data) can be
On 9/9/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Python unittest TestCase objects have a lot of helper functions like
> assert_(), failUnless(), assertEqual(), assertNotEqual() and so on[1]. If we
> had a similar set of helper functions, possibly with more pythonic names,
> newform validation
Python unittest TestCase objects have a lot of helper functions like
assert_(), failUnless(), assertEqual(), assertNotEqual() and so on[1]. If we
had a similar set of helper functions, possibly with more pythonic names,
newform validation functions could be written a little more succinctly.
de
19 matches
Mail list logo
