On Tue, 15 Jul 2008 06:32:53 pm Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
> > On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote:
> > > FWIW, I meant 10 != not not 10.
> > >
> > >>> 10 != not not 10
> >
> > File "", line 1
> > 10 != not not 10
> > ^
> >
Steven D'Aprano writes:
> On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote:
>
> > FWIW, I meant 10 != not not 10.
>
> >>> 10 != not not 10
> File "", line 1
> 10 != not not 10
> ^
> SyntaxError: invalid syntax
>
> With respect, I think that the fact that you
On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote:
> FWIW, I meant 10 != not not 10.
>>> 10 != not not 10
File "", line 1
10 != not not 10
^
SyntaxError: invalid syntax
With respect, I think that the fact that you made an analogy with Python
code that you hadn't tested
On Mon, 14 Jul 2008 09:54:16 am Steve Holden wrote:
> > Python may be Guido's language, and if he wants to use his
> > dictatorial powers to say that tests must be written as positive
> > assertions because that's the way he likes it, that's his
> > prerogative. But let's not pretend that this part
Tristan Seligmann writes:
> * Stephen J. Turnbull <[EMAIL PROTECTED]> [2008-07-14 08:51:27 +0900]:
>
> > The analogy to the fact that True != not not 10 is telling, I think.
>
> What?
>
> >>> True == (not not 10)
> True
FWIW, I meant 10 != not not 10.
_
Steve Holden wrote:
"Fail" isn't a negative.
That depends on what you're trying to find out by reading
the code. If you're trying to find out under what conditions
the test succeeds, then it succeeds if it doesn't fail, so
you have a negative.
Whichever convention is chosen, there will be sit
Ben Finney wrote:
That's another reason to avoid "assert" in the name: these methods
*don't* necessarily use the 'assert' statement. Avoiding the
implication that they do use that is a good thing.
Perhaps some positive alternative such as "verify" could
be used instead.
--
Greg
__
* Stephen J. Turnbull <[EMAIL PROTECTED]> [2008-07-14 08:51:27 +0900]:
> The analogy to the fact that True != not not 10 is telling, I think.
What?
>>> True == (not not 10)
True
--
mithrandi, i Ainil en-Balandor, a faer Ambar
signature.asc
Description: Digital signature
__
Steven D'Aprano wrote:
On Mon, 14 Jul 2008 04:19:57 am Mark Hammond wrote:
try to stick to the issue at hand
I'm sorry, did I reply to the wrong message? I thought this was part of
a thread titled "unittest's redundant assertions: asserts vs.
failIf/Unlesses". What *is* the issue at hand if
On Mon, 14 Jul 2008 04:19:57 am Mark Hammond wrote:
> try to stick to the issue at hand
I'm sorry, did I reply to the wrong message? I thought this was part of
a thread titled "unittest's redundant assertions: asserts vs.
failIf/Unlesses". What *is* the issue at hand if not the question of
p
Steve Holden writes:
> "Fail" isn't a negative. As Guido said, it's a description of the test
> behavior under particular circumstances.
This is not true, however. "Fail" is a description of a potentailly
very large class of behaviors. Knowing that the test failed does not
tell you which of
Antoine Pitrou wrote:
Ben Finney benfinney.id.au> writes:
That would better be written (preferring PEP 8 names)
"fail_unless_equal".
Which is still a double negative ("fail" and "unless" are both negative words).
That's another reason to avoid "assert" in the name: these methods
*don't* n
> On Mon, 14 Jul 2008 12:45:58 am Michael Foord wrote:
>
> > I tend to think of testing as action followed by assertion -
> > I do this and this should have happened. Your tests usually define
> > 'expected behaviour' rather than defining how your code won't fail...
>
> Who is the "your" that you
On Mon, 14 Jul 2008 12:39:48 am Antoine Pitrou wrote:
> Let's split hairs a little...
>
> Steve Holden holdenweb.com> writes:
> > "Fail" isn't a negative. As Guido said, it's a description of the
> > test behavior under particular circumstances.
>
> In most circumstances, "fail" is a negative word
Antoine Pitrou wrote:
Let's split hairs a little...
Steve Holden holdenweb.com> writes:
"Fail" isn't a negative. As Guido said, it's a description of the test
behavior under particular circumstances.
In most circumstances, "fail" is a negative word defined as the contrary of
something else (
On Mon, 14 Jul 2008 12:45:58 am Michael Foord wrote:
> I tend to think of testing as action followed by assertion -
> I do this and this should have happened. Your tests usually define
> 'expected behaviour' rather than defining how your code won't fail...
Who is the "your" that you are speaking
Antoine Pitrou wrote:
Let's split hairs a little...
Steve Holden holdenweb.com> writes:
"Fail" isn't a negative. As Guido said, it's a description of the test
behavior under particular circumstances.
In most circumstances, "fail" is a negative word defined as the contrary of
somethin
Antoine Pitrou <[EMAIL PROTECTED]> writes:
> Ben Finney benfinney.id.au> writes:
> > That would better be written (preferring PEP 8 names)
> > "fail_unless_equal".
>
> Which is still a double negative ("fail" and "unless" are both
> negative words).
Hmm, not to this native-English-speaker's ear
Antoine Pitrou wrote:
Ben Finney benfinney.id.au> writes:
That would better be written (preferring PEP 8 names)
"fail_unless_equal".
Which is still a double negative ("fail" and "unless" are both negative words).
"Fail" isn't a negative. As Guido said, it's a description of the test
behavio
Andrew Bennetts <[EMAIL PROTECTED]> writes:
> On the other hand, “assert*” names are positive statements of what
> the behaviour of the system-under-test is.
That statement is better made by the name of the test case. The method
used for implementing the test shouldn't need to be part of that
sta
Antoine Pitrou <[EMAIL PROTECTED]> writes:
> The problem with "fail*" is that you get names like "failIfNotEqual"
That would better be written (preferring PEP 8 names)
"fail_unless_equal".
> (or perhaps even "failUnlessNotEqual")
idem, "fail_if_equal".
> which are double negatives
Exactly. Wi
Ben Finney wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> writes:
[...]
> > I like using only the assertKeyword variants, removing assert_, fail*,
> > and assertEquals.
>
> I'm the opposite. I prefer the 'fail*' variants over the 'assert*'
> variants, because "fail" tells me exactly what the func
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> Same here; let's tread carefully here and not change this with 3.0.
> Starting to deprecate in 3.1 and killing in 3.3 would be soon enough.
I'm very glad this is on the table. Even though I'd really like to see
the names become PEP-8-conformant in
Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 5:16 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Mar 19, 2008 at 2:15 PM, <[EMAIL PROTECTED]> wrote:
>> >
>> > On 02:21 pm, [EMAIL PROTECTED] wrote:
>> > >>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fin
On Mon, Apr 7, 2008 at 7:37 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2008 at 5:16 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 19, 2008 at 2:15 PM, <[EMAIL PROTECTED]> wrote:
> > >
> > > On 02:21 pm, [EMAIL PROTECTED] wrote:
> > > >>OTOH, I'd rat
On Wed, Mar 19, 2008 at 5:16 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2008 at 2:15 PM, <[EMAIL PROTECTED]> wrote:
> >
> > On 02:21 pm, [EMAIL PROTECTED] wrote:
> > >>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
> > >>with me.
> > >
> > >T
Leif Walsh wrote:
> On Wed, Mar 19, 2008 at 7:05 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
>> > This strikes me as a gratuitous API change of the kind Guido was
>> > warning about in his recent post: "Don't change your APIs incompatibly
>> > when porting to Py3k"
>>
>> This seems compelling t
On Wed, Mar 19, 2008 at 7:05 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> > This strikes me as a gratuitous API change of the kind Guido was
> > warning about in his recent post: "Don't change your APIs incompatibly
> > when porting to Py3k"
>
> This seems compelling to me. And as Glyph mentio
On Wed, Mar 19, 2008 at 2:15 PM, <[EMAIL PROTECTED]> wrote:
>
> On 02:21 pm, [EMAIL PROTECTED] wrote:
> >>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
> >>with me.
> >
> >This strikes me as a gratuitous API change of the kind Guido was
> >warning about in his recent
On 19/03/2008, Michael Urman <[EMAIL PROTECTED]> wrote:
> > OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
> > with me.
>
>
> This strikes me as a gratuitous API change of the kind Guido was
> warning about in his recent post: "Don't change your APIs incompatibly
> when po
On Wed, Mar 19, 2008 at 5:02 PM, Jonathan Lange <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2008 at 6:24 PM, Gabriel Grant <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > This gem from unittest.py is pretty much the opposite of "one obvious
> way":
> >
> > # Synonyms for assertion method
On Wed, Mar 19, 2008 at 10:12 AM, Michael Urman <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2008 at 10:44 AM, Stephen J. Turnbull
> <[EMAIL PROTECTED]> wrote:
> > So we should add this to 2to3, no? They're going to run that anyway.
>
> If 2to3 can handle this, that removes the larger half of
Jonathan Lange wrote:
> On Wed, Mar 19, 2008 at 6:24 PM, Gabriel Grant <[EMAIL PROTECTED]> wrote:
>
>> Hi all,
>>
>> This gem from unittest.py is pretty much the opposite of "one obvious way":
>>
>> # Synonyms for assertion methods
>>
>>
> [snip]
>
>> Could these be removed for 3k?
On Wed, Mar 19, 2008 at 6:24 PM, Gabriel Grant <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This gem from unittest.py is pretty much the opposite of "one obvious way":
>
> # Synonyms for assertion methods
>
[snip]
>
> Could these be removed for 3k?
>
I agree with others who say that we shouldn't
On 02:21 pm, [EMAIL PROTECTED] wrote:
>>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
>>with me.
>
>This strikes me as a gratuitous API change of the kind Guido was
>warning about in his recent post: "Don't change your APIs incompatibly
>when porting to Py3k"
I agree empha
On Wed, Mar 19, 2008 at 10:44 AM, Stephen J. Turnbull
<[EMAIL PROTECTED]> wrote:
> So we should add this to 2to3, no? They're going to run that anyway.
If 2to3 can handle this, that removes the larger half of my objection.
I was under the impression that this kind of semantic inferencing was
bey
Gabriel Grant wrote:
> Hi all,
>
> This gem from unittest.py is pretty much the opposite of "one obvious way":
>
> # Synonyms for assertion methods
>
> assertEqual = assertEquals = failUnlessEqual
>
> assertNotEqual = assertNotEquals = failIfEqual
>
> assertAlmostEqual = assertAlmos
2008/3/19, Barry Warsaw <[EMAIL PROTECTED]>:
> > +1 to assert* from me. the fail* variants always feel like
> > double-negatives. I also always use assertTrue instead of assert_. But
> > I don't care enough to argue about it. :)
+1 to the plain affirmative propositions (assert*) instead of the
Michael Urman writes:
> Yes it removes redundancy, but it really doesn't change the cognitive
> load (at least for native speakers).
Actually, OONTDI is important to me, cognitively. Multiple names
implies the possibility of multiple semantics, often unintentionally.
Here that can't be the cas
> OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
> with me.
This strikes me as a gratuitous API change of the kind Guido was
warning about in his recent post: "Don't change your APIs incompatibly
when porting to Py3k"
Yes it removes redundancy, but it really doesn't change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 19, 2008, at 3:20 AM, Jeffrey Yasskin wrote:
> +1 to assert* from me. the fail* variants always feel like
> double-negatives. I also always use assertTrue instead of assert_. But
> I don't care enough to argue about it. :)
I'm in the camp that
+1 to assert* from me. the fail* variants always feel like
double-negatives. I also always use assertTrue instead of assert_. But
I don't care enough to argue about it. :)
On Wed, Mar 19, 2008 at 2:24 AM, Gabriel Grant <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This gem from unittest.py is pretty m
Hi all,
This gem from unittest.py is pretty much the opposite of "one obvious way":
# Synonyms for assertion methods
assertEqual = assertEquals = failUnlessEqual
assertNotEqual = assertNotEquals = failIfEqual
assertAlmostEqual = assertAlmostEquals = failUnlessAlmostEqual
a
43 matches
Mail list logo
