Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
___
Python-bugs-list
Changes by Guido van Rossum gu...@python.org:
--
nosy: -gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
___
Python-bugs-list
Gregory P. Smith g...@krypto.org added the comment:
fyi - Your docs in unittest-assertis.diff mention the wrong method name
(assertIsNotNone instead of assertIsNot). fix that and commit.
The unittest-sameelements.diff patch looks good.
--
___
Michael Foord mich...@voidspace.org.uk added the comment:
Committed in revision 71263. Closing as there is nothing outstanding on
this issue.
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
Changes by Steve Purcell purc...@users.sourceforge.net:
--
nosy: -purcell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
___
Michael Foord mich...@voidspace.org.uk added the comment:
I'd like to add assertIs and assertNotIs.
We have these at work and I would find them useful whilst writing tests
for another set of changes to unittest I'm currently working on!
--
___
Antoine Pitrou pit...@free.fr added the comment:
Le samedi 04 avril 2009 à 15:06 +, Michael Foord a écrit :
Michael Foord mich...@voidspace.org.uk added the comment:
I'd like to add assertIs and assertNotIs.
Let's call it AssertIsNot (we type x is not None, not x not is
None).
Michael Foord mich...@voidspace.org.uk added the comment:
I would *mmuch* prefer assertIsNot but it is not symmetrical with the
other asserts.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
Antoine Pitrou pit...@free.fr added the comment:
I would *mmuch* prefer assertIsNot but it is not symmetrical with the
other asserts.
Well, apparently assertIsNotNone() has been added, so it would be good
to be symmetrical with that :)
--
___
Benjamin Peterson benja...@python.org added the comment:
I found while merging this to Py3k that dicts can't be used in
assertSameElements because they are unorderable in py3k.
--
___
Python tracker rep...@bugs.python.org
Michael Foord mich...@voidspace.org.uk added the comment:
Patch with assertIs and assertIsNot. Docs but nothing in NEWS as already
covered.
Ok to apply?
--
Added file: http://bugs.python.org/file13613/unittest-assertis.diff
___
Python tracker
Michael Foord mich...@voidspace.org.uk added the comment:
Patch for Py3k with fallback for comparing unsortable sequences in
assertSameElements.
Removed the expected failure and added another test case to confirm that
this patch works for unsortable sequences that are the same (no fail)
and
Antoine Pitrou pit...@free.fr added the comment:
Seeing how a change in assertNotEqual unveiled a bug in OrderedDict,
would it be desireable for each of assertEqual and assertNotEqual to
test both the '!=' and '==' operators?
--
___
Python tracker
Nick Coghlan ncogh...@gmail.com added the comment:
No, because the rich comparison docs explicitly state that the
interpreter makes no assumptions about the relationship between != and
== (or, more precisely, __eq__ and __ne__).
There are no implied relationships among the comparison operators.
Michael Foord mich...@voidspace.org.uk added the comment:
Why is assertMultiLineEqual not the default assert method for basestring?
Even for small strings the output is useful.
--
___
Python tracker rep...@bugs.python.org
Gregory P. Smith g...@krypto.org added the comment:
assertMultiLineEqual might be reasonable as a default assertEqual for
unicode. I wouldn't want to do it for bytes (py 2.x string).
--
___
Python tracker rep...@bugs.python.org
Michael Foord mich...@voidspace.org.uk added the comment:
Fair point. :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
___
Nick Coghlan ncogh...@gmail.com added the comment:
Bikeshedding a bit - the 'assertGreaterEqual' and 'assertLessEqual'
method names grate on me a little. My brain has to do a double take in
order to correctly insert the implied 'Or'. This reaction is made worse
when these two methods are
Guido van Rossum gu...@python.org added the comment:
Nick Coghlan ncogh...@gmail.com added the comment:
Bikeshedding a bit - the 'assertGreaterEqual' and 'assertLessEqual'
method names grate on me a little. My brain has to do a double take in
order to correctly insert the implied 'Or'. This
Skip Montanaro s...@pobox.com added the comment:
Am I the only person who wishes all the assert* and fail* methods would
simply go away in favor of simply using the assert statement?
Skip
--
___
Python tracker rep...@bugs.python.org
Michael Foord mich...@voidspace.org.uk added the comment:
Why do you need the assert methods to go away in order to use assert
statements?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
Skip Montanaro s...@pobox.com added the comment:
Michael Why do you need the assert methods to go away in order to use
Michael assert statements?
You don't, but use of assert statements seems a hell of a lot more Pythonic
to me than all the assert* or fail* method names which I can never
Antoine Pitrou pit...@free.fr added the comment:
You don't, but use of assert statements seems a hell of a lot more Pythonic
to me than all the assert* or fail* method names which I can never remember.
Two problems:
1. they are optimized away in -Oxxx mode
2. they don't provide good reporting
Nick Coghlan ncogh...@gmail.com added the comment:
Thanks Guido - the __ge__/__le__ parallel does actually help me remember
the current names.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
Skip Montanaro s...@pobox.com added the comment:
You don't, but use of assert statements seems a hell of a lot more
Pythonic to me than all the assert* or fail* method names which I can
never remember.
Antoine 1. they are optimized away in -Oxxx mode
As far as I can tell for
Michael Foord mich...@voidspace.org.uk added the comment:
No - you catch self.failureException rather than AssertionError directly.
I use unittest precisely because of the rich failure information from
the assert methods - particularly the new ones in this patch!
--
Gregory P. Smith g...@krypto.org added the comment:
sounds good. This is done for 2.7.
I will make sure it gets merged into 3.1 properly before closing.
--
versions: -Python 2.7
___
Python tracker rep...@bugs.python.org
Benjamin Peterson benja...@python.org added the comment:
Do you mind if I rename all the double underscore methods that Greg's
patch added to _ underscore matching the style of the rest of the module?
--
___
Python tracker rep...@bugs.python.org
Guido van Rossum gu...@python.org added the comment:
Do I mind? I *insist*! I thought put a note about that in the code
review but I guess Greg missed it. Thanks for noticing.
--
___
Python tracker rep...@bugs.python.org
Benjamin Peterson benja...@python.org added the comment:
Done in r71004.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
___
Guido van Rossum gu...@python.org added the comment:
Hi Greg, I've mostly reviewed for style...
http://codereview.appspot.com/32080/diff/13/1006
File Doc/library/unittest.rst (right):
http://codereview.appspot.com/32080/diff/13/1006#newcode611
Line 611: assertTrue(expr[, msg])
Make assertTrue
Gregory P. Smith g...@krypto.org added the comment:
Reviewers: fuzzyman, GvR,
http://codereview.appspot.com/32080/diff/13/1006
File Doc/library/unittest.rst (right):
http://codereview.appspot.com/32080/diff/13/1006#newcode611
Line 611: assertTrue(expr[, msg])
On 2009/03/31 15:01:06, GvR wrote:
Guido van Rossum gu...@python.org added the comment:
LG.
http://codereview.appspot.com/32080
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
Gregory P. Smith g...@krypto.org added the comment:
Comments applied. committed to trunk in r70837. Needs porting to
python 3.1.
Next changes TODO:
* rename the method def's and add deprecation warnings to fail* variants.
In room discussion at pycon 2009 sprints consensus on Equal vs Equals
Guido van Rossum gu...@python.org added the comment:
I think we should rename the method defs ASAP but not start deprecating
the old names until 3.2. Otherwise many people's tests will be very
noisy and that's just annoying. Give them time to migrate voluntarily.
--
Gregory P. Smith g...@krypto.org added the comment:
def's of the methods changed to be the official assert* names in trunk
r70864. unittests added to confirm that all known method names continue
to work.
Guido - If we fix 2to3 to fixup unittests that use the fail* method
names to use the
Michael Foord mich...@voidspace.org.uk added the comment:
If the deprecation causes noise people can just turn off the deprecation
warning surely?
Especially as transforming a codebase really is as simple as a global
search and replace. Personally I'd prefer earlier deprecation.
--
Gregory P. Smith g...@krypto.org added the comment:
trunk r70878 has the code issue an actual PendingDeprecationWarning for
the fail* methods and documents them as deprecated. If anyone has a
better idea of a better way to state those deprecations in the docs,
feel free to jump in here.
I was
Guido van Rossum gu...@python.org added the comment:
I absolutely do not want it to warn by default in 3.1.
PendingDeprecationError is fine.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
39 matches
Mail list logo
