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 stdin, line 1
10 != not not 10
^
SyntaxError: invalid syntax
With respect, I think that the fact that you made an
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 stdin, line 1
10 != not not 10
^
SyntaxError: invalid
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.
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 particular
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 stdin, 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
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 the
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 function will
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. With if and
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
Antoine Pitrou wrote:
Ben Finney bignose+hates-spam at 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
Antoine Pitrou [EMAIL PROTECTED] writes:
Ben Finney bignose+hates-spam at 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
Antoine Pitrou wrote:
Let's split hairs a little...
Steve Holden steve at 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
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 for
Antoine Pitrou wrote:
Let's split hairs a little...
Steve Holden steve at 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
On Mon, 14 Jul 2008 12:39:48 am Antoine Pitrou wrote:
Let's split hairs a little...
Steve Holden steve at 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
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
Antoine Pitrou wrote:
Ben Finney bignose+hates-spam at 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
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 the
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
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
* 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
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
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
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 fine
with me.
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.
This strikes me as a
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 rather there be OOWTDI
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
+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 much
-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
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 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 case
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
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 = assertAlmostEquals =
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
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 emphatically.
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 do this for
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?
I agree with
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 my
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 methods
[snip]
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 porting to
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 post: Don'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 mentioned, the
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 to me. And as
43 matches
Mail list logo
