unittest: shortDescription, _TextTestResult and other issues
Hello all, I've been looking at outstanding unittest issues as part of my preparation for my PyCon talk. There are a couple of changes (minor) I'd like to make that I thought I ought to run past Python-Dev first. If I don't get any responses then I'll just do it, so you have been warned. :-) The great google merge into unittest happened at PyCon last year [1]. This included a change to TestCase.shortDescription() so that it would *always* include the test name, whereas previously it would return the test docstring or None. The problem this change solved was that tests with a docstring would not have their name (test class and method name) reported during the test run. Unfortunately the change broke part of twisted test running. Reported as issue 7588: http://bugs.python.org/issue7588 It seems to me that the same effect (always reporting test name) can be achieved in _TextTestResult.getDescription(). I propose to revert the change to TestCase.shortDescription() (which has both a horrible name and a horrible implementation and should probably be renamed getDocstring so that what it does is obvious but never mind) and put the change into _TextTestResult. It annoys me that _TextTestResult is private, as you will almost certainly want to use it or subclass it when implementing custom test systems. I am going to rename it TextTestResult, alias the old name and document the old name as being deprecated. Another issue that I would like to address, but there are various possible approaches, is issue 7559: http://bugs.python.org/issue7559 Currently loadTestsFromName catches ImportError and rethrows as AttributeError. This is horrible (it obscures the original error) but there are backwards compatibility issues with fixing it. There are three possible approaches: 1) Leave it (the default) 2) Only throw an AttributeError if the import fails due to the name being invalid (the module not existing) otherwise allow the error through. (A minor but less serious change in behavior). 3) A new method that turns failures into pseudo-tests that fail with the original error when run. Possibly deprecating loadTestsFromName I favour option 3, but can't think of a good replacement name. :-) Comments welcomed. Despite deprecating (in the documentation - no actual deprecations warnings I believe) a lot of the duplicate ways of doing things (assert* favoured over fail* and assertEqual over assertEquals) we didn't include deprecating assert_ in favour of assertTrue. I would like to add that to the documentation. After 3.2 is out I would like to clean up the documentation, removing mention of the deprecated methods from the *main* documentation into a separate 'deprecated methods' section. They currently make the documentation very untidy. The unittest page should probably be split into several pages anyway and needs improving. Other outstanding minor issues: Allow dotted names for test discovery http://bugs.python.org/issue7780 - I intend to implement this as described in the last comment A 'check_order' optional argument (defaulting to True) for assertSequenceEqual http://bugs.python.org/issue7832 - needs patch The breaking of __unittest caused by splitting unittesst into a package needs fixing. The fix needs to work when Python is run without frames support (IronPython). http://bugs.python.org/issue7815 - needs patch Allow a __unittest (or similar) decorator for user implemented assert functions http://bugs.python.org/issue1705520 - needs patch Allow modules to define test_suite callable. http://bugs.python.org/issue7501 - I propose to close as rejected. Use load_tests instead. Display time taken by individual tests when in verbose mode. http://bugs.python.org/issue4080 - anyone any opinions? Allow automatic formatting of arguments in assert* failure messages. http://bugs.python.org/issue6966 - I propose to close as rejected removeTest() method on TestSuite http://bugs.python.org/issue1778410 - anyone any opinions? expect methods (delayed fail) http://bugs.python.org/issue3615 - any opinions? Personally I think that the TestCase API is big enough already All the best, Michael Foord [1] Mostly in revision 7-837. http://svn.python.org/view?view=rev&revision=70837 -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
I missed another minor issue. In the interests of completeness... You currently have to subclass TextTestRunner (and override _makeResult) for it to use a custom TestResult. Implementing a custom test result is one of extensibility points of unittest, so I propose adding an optional argument to TextTestRunner allowing you to pass in a result class (or other callable) that _makeResult will use to create the result object. Should be uncontroversial. :-) http://bugs.python.org/issue7893 Michael On 09/02/2010 16:40, Michael Foord wrote:
Hello all,
I've been looking at outstanding unittest issues as part of my preparation for my PyCon talk. There are a couple of changes (minor) I'd like to make that I thought I ought to run past Python-Dev first. If I don't get any responses then I'll just do it, so you have been warned. :-)
The great google merge into unittest happened at PyCon last year [1]. This included a change to TestCase.shortDescription() so that it would *always* include the test name, whereas previously it would return the test docstring or None.
The problem this change solved was that tests with a docstring would not have their name (test class and method name) reported during the test run. Unfortunately the change broke part of twisted test running. Reported as issue 7588:
http://bugs.python.org/issue7588
It seems to me that the same effect (always reporting test name) can be achieved in _TextTestResult.getDescription(). I propose to revert the change to TestCase.shortDescription() (which has both a horrible name and a horrible implementation and should probably be renamed getDocstring so that what it does is obvious but never mind) and put the change into _TextTestResult.
It annoys me that _TextTestResult is private, as you will almost certainly want to use it or subclass it when implementing custom test systems. I am going to rename it TextTestResult, alias the old name and document the old name as being deprecated.
Another issue that I would like to address, but there are various possible approaches, is issue 7559: http://bugs.python.org/issue7559 Currently loadTestsFromName catches ImportError and rethrows as AttributeError. This is horrible (it obscures the original error) but there are backwards compatibility issues with fixing it. There are three possible approaches:
1) Leave it (the default) 2) Only throw an AttributeError if the import fails due to the name being invalid (the module not existing) otherwise allow the error through. (A minor but less serious change in behavior). 3) A new method that turns failures into pseudo-tests that fail with the original error when run. Possibly deprecating loadTestsFromName
I favour option 3, but can't think of a good replacement name. :-)
Comments welcomed.
Despite deprecating (in the documentation - no actual deprecations warnings I believe) a lot of the duplicate ways of doing things (assert* favoured over fail* and assertEqual over assertEquals) we didn't include deprecating assert_ in favour of assertTrue. I would like to add that to the documentation. After 3.2 is out I would like to clean up the documentation, removing mention of the deprecated methods from the *main* documentation into a separate 'deprecated methods' section. They currently make the documentation very untidy. The unittest page should probably be split into several pages anyway and needs improving.
Other outstanding minor issues:
Allow dotted names for test discovery http://bugs.python.org/issue7780 - I intend to implement this as described in the last comment
A 'check_order' optional argument (defaulting to True) for assertSequenceEqual http://bugs.python.org/issue7832 - needs patch
The breaking of __unittest caused by splitting unittesst into a package needs fixing. The fix needs to work when Python is run without frames support (IronPython). http://bugs.python.org/issue7815 - needs patch
Allow a __unittest (or similar) decorator for user implemented assert functions http://bugs.python.org/issue1705520 - needs patch
Allow modules to define test_suite callable. http://bugs.python.org/issue7501 - I propose to close as rejected. Use load_tests instead.
Display time taken by individual tests when in verbose mode. http://bugs.python.org/issue4080 - anyone any opinions?
Allow automatic formatting of arguments in assert* failure messages. http://bugs.python.org/issue6966 - I propose to close as rejected
removeTest() method on TestSuite http://bugs.python.org/issue1778410 - anyone any opinions?
expect methods (delayed fail) http://bugs.python.org/issue3615 - any opinions? Personally I think that the TestCase API is big enough already
All the best,
Michael Foord
[1] Mostly in revision 7-837. http://svn.python.org/view?view=rev&revision=70837
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Michael Foord <michael@voidspace.org.uk> writes:
It seems to me that the same effect (always reporting test name) can be achieved in _TextTestResult.getDescription(). I propose to revert the change to TestCase.shortDescription() (which has both a horrible name and a horrible implementation and should probably be renamed getDocstring so that what it does is obvious but never mind) and put the change into _TextTestResult.
I understood the point of ‘TestCase.shortDescription’, and indeed the point of that particular name, was to be clear that some *other* text could be the short description for the test case. Indeed, this is what you've come up with: a different implementation for generating a short description. The default implementation uses *part of* the docstring (the PEP 257 specified single-line summary), but that's just one possible way to make a short test case description. Calling it ‘getDocstring’ would not only be disruptive, but clearly false even in the default implementation. I've overridden that method to provide better, more specific, test case short descriptions, and the name works fine since I'm providing an overridden implementation of “the short description of this test case”. I've even presented a patch to the third-party ‘testscenarios’ library to decorate the short description with the scenario name. I'd suggest this method, with its existing name, is the correct way to embellish test case descriptions for report output. -- \ “I do not believe in forgiveness as it is preached by the | `\ church. We do not need the forgiveness of God, but of each | _o__) other and of ourselves.” —Robert G. Ingersoll | Ben Finney
On Tue, Feb 9, 2010 at 4:50 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
Michael Foord <michael@voidspace.org.uk> writes:
It seems to me that the same effect (always reporting test name) can be achieved in _TextTestResult.getDescription(). I propose to revert the change to TestCase.shortDescription() (which has both a horrible name and a horrible implementation and should probably be renamed getDocstring so that what it does is obvious but never mind) and put the change into _TextTestResult.
[...]
I've overridden that method to provide better, more specific, test case short descriptions, and the name works fine since I'm providing an overridden implementation of “the short description of this test case”.
Oh yes ! Thnx for mentioning that ! Very much ! If you move or remove shortDescription then I think dutest will be broken. In that case there is an automatically generated short description comprising the doctest name or id (e.g. class name + method name ;o) and example index (just remember that every interactive example is considered to be a test case ;o) In that case there is no other way to get this done unless an all-mighty & heavy test result be implemented . So I am *VERY* -1 for removing `shortDescription` (and I also think that TC should be the one to provide the short desc rather than the test result, just like what Ben Finney said before ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: PEP 391 - Please Vote! - http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617
On 09/02/2010 22:22, Olemis Lang wrote:
On Tue, Feb 9, 2010 at 4:50 PM, Ben Finney<ben+python@benfinney.id.au> wrote:
Michael Foord<michael@voidspace.org.uk> writes:
It seems to me that the same effect (always reporting test name) can be achieved in _TextTestResult.getDescription(). I propose to revert the change to TestCase.shortDescription() (which has both a horrible name and a horrible implementation and should probably be renamed getDocstring so that what it does is obvious but never mind) and put the change into _TextTestResult.
[...]
I've overridden that method to provide better, more specific, test case short descriptions, and the name works fine since I'm providing an overridden implementation of “the short description of this test case”.
Oh yes ! Thnx for mentioning that ! Very much !
If you move or remove shortDescription then I think dutest will be broken. In that case there is an automatically generated short description comprising the doctest name or id (e.g. class name + method name ;o) and example index (just remember that every interactive example is considered to be a test case ;o)
I am *not* suggesting removing shortDescription I am suggesting reverting to its behavior in Python 2.6. That would not affect your or Ben's use case (obviously). Given the name 'short description' it is being argued that making the description longer by adding the test name is inappropriate and that if this needs to be reported (which it should be) then this rightly belongs in the TestResult. Michael Foord
In that case there is no other way to get this done unless an all-mighty& heavy test result be implemented .
So I am *VERY* -1 for removing `shortDescription` (and I also think that TC should be the one to provide the short desc rather than the test result, just like what Ben Finney said before ;o)
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On 09/02/2010 21:50, Ben Finney wrote:
Michael Foord<michael@voidspace.org.uk> writes:
It seems to me that the same effect (always reporting test name) can be achieved in _TextTestResult.getDescription(). I propose to revert the change to TestCase.shortDescription() (which has both a horrible name and a horrible implementation and should probably be renamed getDocstring so that what it does is obvious but never mind) and put the change into _TextTestResult.
I understood the point of ‘TestCase.shortDescription’, and indeed the point of that particular name, was to be clear that some *other* text could be the short description for the test case. Indeed, this is what you've come up with: a different implementation for generating a short description.
The default implementation uses *part of* the docstring (the PEP 257 specified single-line summary), but that's just one possible way to make a short test case description. Calling it ‘getDocstring’ would not only be disruptive, but clearly false even in the default implementation.
I'm not actually suggesting doing that - I was just musing out loud. So do you think the *new* implementation would be better, given that it breaks part of the twisted test suite, or would you be fine with me putting the current change into TestResult instead? Given that the change broke something, and the desired effect can be gained with a different change, I don't really see a downside to the change I'm proposing (reverting shortDescription and moving the code that adds the test name to TestResult). Michael
I've overridden that method to provide better, more specific, test case short descriptions, and the name works fine since I'm providing an overridden implementation of “the short description of this test case”. I've even presented a patch to the third-party ‘testscenarios’ library to decorate the short description with the scenario name.
I'd suggest this method, with its existing name, is the correct way to embellish test case descriptions for report output.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Michael Foord <fuzzyman@voidspace.org.uk> writes:
On 09/02/2010 21:50, Ben Finney wrote:
I understood the point of ‘TestCase.shortDescription’, and indeed the point of that particular name, was to be clear that some *other* text could be the short description for the test case. Indeed, this is what you've come up with: a different implementation for generating a short description.
Given that the change broke something, and the desired effect can be gained with a different change, I don't really see a downside to the change I'm proposing (reverting shortDescription and moving the code that adds the test name to TestResult).
What you describe (adding the class and method name when reporting the test) sounds like it belongs in the TestRunner, since it's more a case of “give me more information about the test result”. That is, a TestRunner that reports each result *with* the extra information would be useful, for some cases, but should not modify the TestResult instance to do that. Am I right that this approach would avoid breakage in the case of frameworks that don't expect their TestRunner to behave that way? e.g. Twisted could simply use the TestRunner that doesn't behave this way, and (since the TestResult instances aren't any different) continue to get the expected behaviour. -- \ “If nothing changes, everything will remain the same.” —Barne's | `\ Law | _o__) | Ben Finney
On 10/02/2010 01:07, Ben Finney wrote:
Michael Foord<fuzzyman@voidspace.org.uk> writes:
On 09/02/2010 21:50, Ben Finney wrote:
I understood the point of ‘TestCase.shortDescription’, and indeed the point of that particular name, was to be clear that some *other* text could be the short description for the test case. Indeed, this is what you've come up with: a different implementation for generating a short description.
Given that the change broke something, and the desired effect can be gained with a different change, I don't really see a downside to the change I'm proposing (reverting shortDescription and moving the code that adds the test name to TestResult).
What you describe (adding the class and method name when reporting the test) sounds like it belongs in the TestRunner, since it's more a case of “give me more information about the test result”.
The code for giving information about individual test results is the TestResult. The TestRunner knows nothing about each individual result (or even about each individual test as it happens). The TestRunner is responsible for the whole test run, the TestCase runs individual tests and the TestResult reports (or holds) individual test results (at the behest of the TestCase). Given this structure it is not possible for test descriptions to be the responsibility of the TestRunner and I don't feel like re-structuring unittest today. :-) Michael
That is, a TestRunner that reports each result *with* the extra information would be useful, for some cases, but should not modify the TestResult instance to do that.
Am I right that this approach would avoid breakage in the case of frameworks that don't expect their TestRunner to behave that way? e.g. Twisted could simply use the TestRunner that doesn't behave this way, and (since the TestResult instances aren't any different) continue to get the expected behaviour.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Wed, Feb 10, 2010 at 6:11 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
On 10/02/2010 01:07, Ben Finney wrote:
Michael Foord<fuzzyman@voidspace.org.uk> writes:
On 09/02/2010 21:50, Ben Finney wrote:
I understood the point of ‘TestCase.shortDescription’, and indeed the point of that particular name, was to be clear that some *other* text could be the short description for the test case. Indeed, this is what you've come up with: a different implementation for generating a short description.
Given that the change broke something, and the desired effect can be gained with a different change, I don't really see a downside to the change I'm proposing (reverting shortDescription and moving the code that adds the test name to TestResult).
What you describe (adding the class and method name when reporting the test) sounds like it belongs in the TestRunner, since it's more a case of “give me more information about the test result”.
The code for giving information about individual test results is the TestResult. The TestRunner knows nothing about each individual result (or even about each individual test as it happens). The TestRunner is responsible for the whole test run, the TestCase runs individual tests and the TestResult reports (or holds) individual test results (at the behest of the TestCase).
Given this structure it is not possible for test descriptions to be the responsibility of the TestRunner and I don't feel like re-structuring unittest today. :-)
FWIW +1 -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Nabble - Trac Users - Embedding pages? - http://feedproxy.google.com/~r/TracGViz-full/~3/MWT7MJBi08w/Embedding-pages-...
Michael Foord wrote:
Given that the change broke something, and the desired effect can be gained with a different change, I don't really see a downside to the change I'm proposing (reverting shortDescription and moving the code that adds the test name to TestResult).
+1 on fixing this in a way that doesn't break third-party tests :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On 11/02/2010 12:13, Nick Coghlan wrote:
Michael Foord wrote:
Given that the change broke something, and the desired effect can be gained with a different change, I don't really see a downside to the change I'm proposing (reverting shortDescription and moving the code that adds the test name to TestResult).
+1 on fixing this in a way that doesn't break third-party tests :)
It is done. The slight disadvantage is that overriding shortDescription on your own TestCase no longer removes the test name from being added to the short description. On the other hand if you do override shortDescription you don't have to add the test name yourself, and using a custom TestResult (overriding getDescription) is much easier now that the TextTestRunner takes a resultclass argument in the constructor. All the best, Michael
Cheers, Nick.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Michael Foord <fuzzyman@voidspace.org.uk> writes:
It is done. The slight disadvantage is that overriding shortDescription on your own TestCase no longer removes the test name from being added to the short description.
That's a significant disadvantage; it can easily double the length of the reported description for a test case. Before: The Wodget should spangulate with the specified doohickey... ok After: test_zwickyblatt.MechakuchaWidget.test_spangulates_with_specified_doohickey: The Wodget should spangulate with the specified doohickey... ok (if I have the new description incorrect feel free to correct me, but I think the point is clear about adding the test name to the description). Reports that before would mostly stay within a standard 80-column terminal will now almost always be line-wrapping, making the output much harder to read.
On the other hand if you do override shortDescription you don't have to add the test name yourself
The problem isn't only with overridden shortDescription. The problem is the breakage in the existing behaviour of shortDescription, even in cases that never needed to override shortDescription.
and using a custom TestResult (overriding getDescription) is much easier now that the TextTestRunner takes a resultclass argument in the constructor.
Again, it seems that adding this to the output is the job of the thing which does the reporting, *if* wanted. The (long!) name isn't part of the TestCase description, so shouldn't be bolted onto the TestResult description. -- \ Moriarty: “Forty thousand million billion dollars? That money | `\ must be worth a fortune!” —The Goon Show, _The Sale of | _o__) Manhattan_ | Ben Finney
On 11/02/2010 22:03, Ben Finney wrote:
Michael Foord<fuzzyman@voidspace.org.uk> writes:
It is done. The slight disadvantage is that overriding shortDescription on your own TestCase no longer removes the test name from being added to the short description.
That's a significant disadvantage; it can easily double the length of the reported description for a test case.
Before:
The Wodget should spangulate with the specified doohickey... ok
After:
test_zwickyblatt.MechakuchaWidget.test_spangulates_with_specified_doohickey: The Wodget should spangulate with the specified doohickey... ok
There is a newline between the testname and the first line of the docstring. If there is no docstring behaviour is completely unchanged. This is how it was in the 2.7 codebase before I made the change and is unchanged. The only difference is that you don't lose this behaviour by overriding TestCase.shortDescription().
(if I have the new description incorrect feel free to correct me, but I think the point is clear about adding the test name to the description).
Reports that before would mostly stay within a standard 80-column terminal will now almost always be line-wrapping, making the output much harder to read.
On the other hand if you do override shortDescription you don't have to add the test name yourself
The problem isn't only with overridden shortDescription. The problem is the breakage in the existing behaviour of shortDescription, even in cases that never needed to override shortDescription.
shortDescription itself is now unchanged from Python 2.6.
and using a custom TestResult (overriding getDescription) is much easier now that the TextTestRunner takes a resultclass argument in the constructor.
Again, it seems that adding this to the output is the job of the thing which does the reporting, *if* wanted. The (long!) name isn't part of the TestCase description, so shouldn't be bolted onto the TestResult description.
Well, it *is* the TextTestResult that does the reporting. Don't believe me - look at the code. Test results are reported (written to the output stream) by the TextTestResult. Actually my description above was slightly incorrect - it is only TextTestResult that has a getDescription method, so custom TestResult implementations that inherit directly from TestResult will now also have unchanged behavior from 2.6 in this regard. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Michael Foord <fuzzyman@voidspace.org.uk> writes:
There is a newline between the testname and the first line of the docstring. If there is no docstring behaviour is completely unchanged. […]
shortDescription itself is now unchanged from Python 2.6.
Thanks, that completely addresses and satisfies my concerns about the test case reporting. Great work, Michael; not only in the coding, but especially in the communication about these changes. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney
participants (6)
-
Ben Finney -
Michael Foord -
Michael Foord -
Michael Foord -
Nick Coghlan -
Olemis Lang