On 12/24/2010 02:03 PM, Raymond Hettinger wrote:
On Dec 24, 2010, at 10:56 AM, Terry Reedy wrote:
On 12/24/2010 11:09 AM, Michael Foord wrote:
On 22/12/2010 02:26, Terry Reedy wrote:
On 12/21/2010 7:17 AM, Michael Foord wrote:
My first priority is that doc and code match.
Close second is
On Dec 24, 2010, at 10:56 AM, Terry Reedy wrote:
> On 12/24/2010 11:09 AM, Michael Foord wrote:
>> On 22/12/2010 02:26, Terry Reedy wrote:
>>> On 12/21/2010 7:17 AM, Michael Foord wrote:
>>>
>>> My first priority is that doc and code match.
>>> Close second is consistency (hence, ease of learnin
On 12/24/2010 11:09 AM, Michael Foord wrote:
On 22/12/2010 02:26, Terry Reedy wrote:
On 12/21/2010 7:17 AM, Michael Foord wrote:
My first priority is that doc and code match.
Close second is consistency (hence, ease of learning and use) between
various AssertXs.
Symmetrical diffs (element in
On 22/12/2010 02:26, Terry Reedy wrote:
On 12/21/2010 7:17 AM, Michael Foord wrote:
My first priority is that doc and code match.
Close second is consistency (hence, ease of learning and use) between
various AssertXs.
Symmetrical diffs (element in first not in second, element in second not
i
On 22 December 2010 01:37, Guido van Rossum wrote:
> Furthermore, Java's jUnit puts expected first (and makes this part of
> the culture/religion), so people coming from there will use that order
> and be freaked out if you were to swap them. And last, the order of
> diff arguments (old new) is al
On 12/21/2010 7:17 AM, Michael Foord wrote:
My first priority is that doc and code match.
Close second is consistency (hence, ease of learning and use) between
various AssertXs.
Symmetrical diffs (element in first not in second, element in second not
in first) solves the problem without impos
On Tue, Dec 21, 2010 at 5:12 PM, Nick Coghlan wrote:
> I actually agree with Guido that anything we do is going to be
> suboptimal in some way. Encouraging the actual/expected ordering and
> updating the diff output so "expected=old" strikes me as least bad,
> but using the neutral first/second te
On Tue, Dec 21, 2010 at 11:17 PM, Michael Foord
wrote:
> On 21/12/2010 01:57, Nick Coghlan wrote:
>> My own +1 goes to keeping the actual/expected terminology (and
>> ordering) and adjusting the diffs accordingly (with a header noting
>> that the diff is old=expected, new=actual).
>>
>
> Well we d
On Tue, Dec 21, 2010 at 4:17 AM, Michael Foord
wrote:
> On 21/12/2010 01:57, Nick Coghlan wrote:
>>
>> On Tue, Dec 21, 2010 at 1:31 AM, Antoine Pitrou
>> wrote:
Diffing is completely an implementation detail of how the failure
messages are generated. The important thing is that fai
On 12/21/2010 4:17 AM, Michael Foord wrote:
Glenn Linderman wants (actual, expected) and diffing to follow that
If you say that is what I said, fine. I might not have understood the
example well enough to say the right thing. I liked Nick's explanation,
using the actual and expected words i
On 21/12/2010 01:57, Nick Coghlan wrote:
On Tue, Dec 21, 2010 at 1:31 AM, Antoine Pitrou wrote:
Diffing is completely an implementation detail of how the failure
messages are generated. The important thing is that failure messages
make sense with respect to actual result and expected result.
W
On Tue, Dec 21, 2010 at 1:31 AM, Antoine Pitrou wrote:
>> Diffing is completely an implementation detail of how the failure
>> messages are generated. The important thing is that failure messages
>> make sense with respect to actual result and expected result.
>
> Which, again, they don't. Let's s
On Mon, Dec 20, 2010 at 1:55 AM, Steven D'Aprano wrote:
> Antoine Pitrou wrote:
>
>> For a non-native English speaker, 'a' and 'b' don't evoke 'after' and
>> 'before' but simply the first two letters of the latin alphabet, and
>> their ordering is therefore obvious with respect to function argumen
On 12/20/2010 6:31 AM, Antoine Pitrou wrote:
> Diffing is completely an implementation detail of how the failure
> messages are generated. The important thing is that failure messages
> make sense with respect to actual result and expected result.
Which, again, they don't. Let's see:
se
On 12/18/2010 04:46 PM, Terry Reedy wrote:
On 12/18/2010 3:48 PM, Antoine Pitrou wrote:
On Sat, 18 Dec 2010 21:00:04 +0100 (CET)
ezio.melotti wrote:
Author: ezio.melotti
Date: Sat Dec 18 21:00:04 2010
New Revision: 87389
Log:
#10573: use actual/expected consistently in unittest methods.
Ch
Le lundi 20 décembre 2010 à 14:03 +, Michael Foord a écrit :
> On 20/12/2010 13:47, Antoine Pitrou wrote:
> > Le lundi 20 décembre 2010 à 13:00 +, Michael Foord a écrit :
> >> Ah man, we've *nearly* finished bikeshedding about the names of unittest
> >> assert methods so its time to move on
On 20/12/2010 13:47, Antoine Pitrou wrote:
Le lundi 20 décembre 2010 à 13:00 +, Michael Foord a écrit :
Ah man, we've *nearly* finished bikeshedding about the names of unittest
assert methods so its time to move onto the names and order of the
arguments. Really?
Apparently someone decided t
Le lundi 20 décembre 2010 à 13:00 +, Michael Foord a écrit :
> Ah man, we've *nearly* finished bikeshedding about the names of unittest
> assert methods so its time to move onto the names and order of the
> arguments. Really?
Apparently someone decided this bikeshedding was important enough
On 19/12/2010 19:55, Raymond Hettinger wrote:
On Dec 19, 2010, at 10:41 AM, Guido van Rossum wrote:
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
On Sat, 18 Dec 2010 20:23:49 -0800
Guido van Rossum wrote:
I may be unique, but I fear there is no great answer. On the one hand
I almos
Antoine Pitrou wrote:
For a non-native English speaker, 'a' and 'b' don't evoke 'after' and
'before' but simply the first two letters of the latin alphabet, and
their ordering is therefore obvious with respect to function arguments.
It's not just non-native English speakers either. I too think
On Sun, 19 Dec 2010 18:54:55 -0500
Terry Reedy wrote:
> On 12/19/2010 1:41 PM, Guido van Rossum wrote:
> > On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
>
> >> This could be nicely resolved by renaming the arguments "a" and "b",
> >> and having the diff display "a, b". It's quite natura
On 12/19/2010 1:41 PM, Guido van Rossum wrote:
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
This could be nicely resolved by renaming the arguments "a" and "b",
and having the diff display "a, b". It's quite natural (both the diff
ordering and the arguments ordering), and they are c
On Dec 19, 2010, at 10:41 AM, Guido van Rossum wrote:
> On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
>> On Sat, 18 Dec 2010 20:23:49 -0800
>> Guido van Rossum wrote:
>>> I may be unique, but I fear there is no great answer. On the one hand
>>> I almost always code it as e.g. assertEqu
Le dimanche 19 décembre 2010 à 10:41 -0800, Guido van Rossum a écrit :
> On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
> > On Sat, 18 Dec 2010 20:23:49 -0800
> > Guido van Rossum wrote:
> >> I may be unique, but I fear there is no great answer. On the one hand
> >> I almost always code i
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
> On Sat, 18 Dec 2010 20:23:49 -0800
> Guido van Rossum wrote:
>> I may be unique, but I fear there is no great answer. On the one hand
>> I almost always code it as e.g. assertEqual(actual, expected), which
>> matches my preference for e.g.
On Sat, 18 Dec 2010 20:23:49 -0800
Guido van Rossum wrote:
> I may be unique, but I fear there is no great answer. On the one hand
> I almost always code it as e.g. assertEqual(actual, expected), which
> matches my preference for e.g. "if x == 5:" rather than "if 5 == x:".
> On the other hand in t
On Sat, 18 Dec 2010 20:23:49 -0800, Guido van Rossum wrote:
> I may be unique, but I fear there is no great answer. On the one hand
> I almost always code it as e.g. assertEqual(actual, expected), which
> matches my preference for e.g. "if x =3D=3D 5:" rather than "if 5 =3D=3D x:=
> ".
> On the ot
I may be unique, but I fear there is no great answer. On the one hand
I almost always code it as e.g. assertEqual(actual, expected), which
matches my preference for e.g. "if x == 5:" rather than "if 5 == x:".
On the other hand in those assert* functions that show a nice diff of
two lists, when read
On 12/18/2010 3:48 PM, Antoine Pitrou wrote:
On Sat, 18 Dec 2010 21:00:04 +0100 (CET)
ezio.melotti wrote:
Author: ezio.melotti
Date: Sat Dec 18 21:00:04 2010
New Revision: 87389
Log:
#10573: use actual/expected consistently in unittest methods.
Change was requested by M. Foord and R. Hetting
On Sat, 18 Dec 2010 21:00:04 +0100 (CET)
ezio.melotti wrote:
> Author: ezio.melotti
> Date: Sat Dec 18 21:00:04 2010
> New Revision: 87389
>
> Log:
> #10573: use actual/expected consistently in unittest methods.
IMHO, this should be reverted. The API currently doesn't treat these
arguments diffe
30 matches
Mail list logo
