Hello
Can I suggest a feature to discuss and hopefully develop and send a PR. I think having a *fail* keyword for unit testing would be great. So we write a test as follows which will fail to begin with.
class MyTest(unittest.TestCase): def test_this_and_that(self): """ Given inputs When action is done Then it should pass """ fail
This keyword is to fill an empty function block like *pass* but this will make the function raise an exception that test is failing. I know there is *raise* but I feel this *fail* keyword is needed to write a test first which fails and then write code and then come back to the test and fill its body.
Umair
--
I do not understand how a simple raise is worse than this. A simple variable holding some standard error (like test not implemented error) should be no different. (like fail = NotImplementedError("Test has not been implemented yet")
I feel like this is a useless syntactic sugar but if you give some real-world examples that could be significantly improved with this keyword, many people here could support it.
On 10/23/20 11:52 AM, Umair Ashraf wrote:
Hello
Howdy!
Can I suggest a feature to discuss and hopefully develop and send a PR.
You can, but the place to do it is Python Ideas:
https://mail.python.org/mailman3/lists/python-ideas.python.org/
python-ideas@python.org
I think having a *fail* keyword for unit testing would be great.
Luckily, we already have it:
assert False
-- ~Ethan~
On 10/23/20 4:50 PM, Steven D'Aprano wrote:
On Fri, Oct 23, 2020 at 01:06:36PM -0700, Ethan Furman wrote:
I think having a *fail* keyword for unit testing would be great.
Luckily, we already have it:
assert FalseI take it you don't run your unit tests under -O :-)
`raise Exception` works fine for me.
Good point. I should start doing that.
-- ~Ethan~
On 24/10/20 7:52 am, Umair Ashraf wrote:
class MyTest(unittest.TestCase): def test_this_and_that(self): """ Given inputs When action is done Then it should pass """ fail
def fail(): raise Exception("It didn't work!")
Not every one-line function needs to be a keyword!
I feel this *fail* keyword is needed to write a test first which fails and then write code and then come back to the test and fill its body.
Um, that's not quite how TDD is supposed to work. You don't explicitly write the *test* so that it fails. You write a proper test, and it fails initially because you haven't yet written the code that it tests.
If you use the unittest module, I suggest you to use self.fail() instead: it is standard. Moreover, you can specify a message. https://docs.python.org/dev/library/unittest.html#unittest.TestCase.fail
Victor
Le ven. 23 oct. 2020 à 21:36, Umair Ashraf umr.ashrf@gmail.com a écrit :
Hello
Can I suggest a feature to discuss and hopefully develop and send a PR. I think having a *fail* keyword for unit testing would be great. So we write a test as follows which will fail to begin with.
class MyTest(unittest.TestCase): def test_this_and_that(self): """ Given inputs When action is done Then it should pass """ fail
This keyword is to fill an empty function block like *pass* but this will make the function raise an exception that test is failing. I know there is *raise* but I feel this *fail* keyword is needed to write a test first which fails and then write code and then come back to the test and fill its body.
Umair
--
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QPOVO34K... Code of Conduct: http://python.org/psf/codeofconduct/
`raise NotImplementedError` https://docs.python.org/3/library/exceptions.html#NotImplementedError I think would be the canonical solution.
E
On Mon, 26 Oct 2020 at 20:34, Victor Stinner vstinner@python.org wrote:
If you use the unittest module, I suggest you to use self.fail() instead: it is standard. Moreover, you can specify a message. https://docs.python.org/dev/library/unittest.html#unittest.TestCase.fail
Victor
Le ven. 23 oct. 2020 à 21:36, Umair Ashraf umr.ashrf@gmail.com a écrit :
Hello
Can I suggest a feature to discuss and hopefully develop and send a PR. I think having a *fail* keyword for unit testing would be great. So we write a test as follows which will fail to begin with.
class MyTest(unittest.TestCase): def test_this_and_that(self): """ Given inputs When action is done Then it should pass """ fail
This keyword is to fill an empty function block like *pass* but this will make the function raise an exception that test is failing. I know there is *raise* but I feel this *fail* keyword is needed to write a test first which fails and then write code and then come back to the test and fill its body.
Umair
--
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QPOVO34K... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/P5LJB2VT... Code of Conduct: http://python.org/psf/codeofconduct/
Hello,
In the context of pattern matching, not accepting a match subject that does not match any of the case clauses is probably going to be frequent if not the most frequent. Thus, when PEP 634, 635, 636 are -- hopefully -- accepted, and experience with the feature is gained, this idea might be worth reconsidering, allowing the rewrite of something like
https://github.com/gvanrossum/patma/blob/master/examples/over.py#L57-L68
``` match args: case [Point2d(x, y)]: return Point3d(x, y, 0) case [p := Point3d()]: return p case [x := int(), y := int()]: return Point3d(x, y, 0) case [x := int(), y := int(), z := int()]: return Point3d(x, y, z) case _: raise TypeError("Huh?") ```
into
``` match args: case [Point2d(x, y)]: ... case ...: ... case ...: ... case ...: ... case _: impossible ```
where `impossible` raises AssertionError.
Best regards, Jean Abou-Samra
On Wed, Oct 28, 2020 at 6:49 AM Jean Abou Samra jean@abou-samra.fr wrote:
where `impossible` raises AssertionError.
Reserving a common English word as a new keyword (whether fail or impossible) is the mother of all breaking changes. The syntactic sugar it provides is not only tiny, it's pretty much negative, since any message it could provide would be too generic to be of much use, versus raising your own relevant exception message.
-Em
On Wed, Oct 28, 2020 at 12:48 PM Emily Bowman silverbacknet@gmail.com wrote:
On Wed, Oct 28, 2020 at 6:49 AM Jean Abou Samra jean@abou-samra.fr wrote:
where `impossible` raises AssertionError.
Reserving a common English word as a new keyword (whether fail or impossible) is the mother of all breaking changes. The syntactic sugar it provides is not only tiny, it's pretty much negative, since any message it could provide would be too generic to be of much use, versus raising your own relevant exception message.
Indeed, especially when you can write this once at the top of your module, or in a utils module in a larger package:
def unreachable(): raise AssertionError
and then Jean's example can be spelled:
match args: case [Point2d(x, y)]: ... case ...: ... case ...: ... case ...: ... case _: unreachable()
Same benefit of a plain English word, identical behavior, very very tiny downside of two parentheses and a two-line function definition, and zero breakage or compatibility issues.
Homonyms are words spelled the same way with different meanings, like bat (flying mammal) and bat (club used to hit a baseball) (btw, club (a blunt instrument) and club (a closed association of people))...
In 22 years of programming Python, I always understood the "pass" keyword as "to forgo an opportunity to act".
Of course, I also use "pass" as the opposite of "fail" in tests, but that was never the meaning of the *pass keyword* for me.
Anyway, I subscribe 100% to Emily Bowman's position: "Reserving a common English word as a new keyword (whether fail or impossible) is the mother of all breaking changes." And the benefit is negative.
Cheers,
Luciano
On Fri, Oct 23, 2020 at 4:42 PM Umair Ashraf umr.ashrf@gmail.com wrote:
Hello
Can I suggest a feature to discuss and hopefully develop and send a PR. I think having a *fail* keyword for unit testing would be great. So we write a test as follows which will fail to begin with.
class MyTest(unittest.TestCase): def test_this_and_that(self): """ Given inputs When action is done Then it should pass """ fail
This keyword is to fill an empty function block like *pass* but this will make the function raise an exception that test is failing. I know there is *raise* but I feel this *fail* keyword is needed to write a test first which fails and then write code and then come back to the test and fill its body.
Umair
--
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QPOVO34K... Code of Conduct: http://python.org/psf/codeofconduct/
-
Emily Bowman -
Ethan Furman -
Evpok Padding -
Greg Ewing -
Jean Abou Samra -
Jonathan Goble -
Luciano Ramalho -
Stanislav Oatmeal -
Steven D'Aprano -
Umair Ashraf -
Victor Stinner