[issue14403] unittest module: provide inverse of "assertRaises"
New submission from Danilo Bargen : Most assert statements of the unittest module provide both an assert statement as well as its inverse, like "assertIn" and "assertNotIn". There is apparently no such thing for exceptions. I can do the following: > with self.assertRaises(SomeException): > do_something() But not: > with self.assertRaisesNot(SomeException): > do_something() I don't want to simply execute the code and hope that it doesn't raise an exception, because if it does, the test fails with an "error" status instead of a "failed" status. A possible workaround is the following code: > try: > do_something() > except SomeException: > self.fail() But that is not that expressive as an assert statement. A naming alternative would be "assertDoesNotRaise". In case this enhancement gets accepted, there should also be an inverse of "assertRaisesRegexp". -- components: Tests messages: 156750 nosy: gwrtheyrn priority: normal severity: normal status: open title: unittest module: provide inverse of "assertRaises" type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue14403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14403] unittest module: provide inverse of "assertRaises"
Danilo Bargen added the comment: >> I don't want to simply execute the code and hope that it doesn't raise >> an exception, because if it does, the test fails with an "error" status >> instead of a "failed" status. > > So what? A buggy test is not the same thing as a test that fails because the test result did not meet your assertions. -- ___ Python tracker <http://bugs.python.org/issue14403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time
Danilo Bargen added the comment:
I disagree, I think this bug should be reopened and fixed.
A use case that I just ran into: I'm using a Django form with time fields that
aren't required, but that are only valid in combination (if there's a open time
there has to be a close time).
if not (self.closed or (self.open_time and self.close_time )):
raise ValidationError("Invalid times")
This leads to a Validation Error when using the times 12:00 and 00:00.
Of course, this case is debatable and can be worked around by using `self.open
is not None and self.close is not None`, but there are even more problems when
using the times inside the template.
I'm using the following widespread pattern inside my templates:
Close time: {{ close_time|default:"-" }}
The "default" filter used in this case displays the string "-" if the value on
the left side of the | symbol evaluates to False. That makes sense in almost
all of the cases.
In the case of the `datetime.time(0, 0)` object, the default value is
displayed, even though `datetime.time(0, 0).__str__()` results in a valid
string (in this case '00:00:00').
(By the way, through these experiments I also found a bug in Django's date
formatting template function caused by this inconsistency, which I will report
separately.)
I agree that casting time objects to a boolean value doesn't make much sense.
But especially because of that, inconsistencies in the resulting boolean value
should NOT exist. Yet another argument for this is that in many regions
midnight isn't considered 00:00, but 24:00, which would obviously not evaluate
to False.
Please fix this. Otherwise it will lead to a whole lot of weird bugs in
software using the datetime library.
--
nosy: +gwrtheyrn
___
Python tracker
<http://bugs.python.org/issue13936>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16791] itertools.chain.from_iterable doesn't stop
Changes by Danilo Bargen : -- nosy: +gwrtheyrn ___ Python tracker <http://bugs.python.org/issue16791> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7434] general pprint rewrite
Changes by Danilo Bargen : -- nosy: +gwrtheyrn ___ Python tracker <http://bugs.python.org/issue7434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17144] Distutils: "sdist register upload" ignores -r argument
New submission from Danilo Bargen: Where I work, we use a custom pypi server to upload our internal packages. With a package that has a setup.py created using setuptools, I can simply issue: $ python setup.py sdist register upload -r local ...and it will get registered and uploaded to our local server. If setup.py is using distutils though, this does not work and the -r argument gets ignored. The command above would register and upload the package to pypi.python.org (which can in some situations be a security problem). As a workaround, this works: $ python setup.py register -r local $ python setup.py sdist upload -r local Tested under Python 2.7... -- assignee: eric.araujo components: Distutils messages: 181540 nosy: eric.araujo, gwrtheyrn, tarek priority: normal severity: normal status: open title: Distutils: "sdist register upload" ignores -r argument type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue17144> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17144] Distutils: "sdist register upload" ignores -r argument
Danilo Bargen added the comment: chris, no, that command registers the package with the local index but tries to upload it to pypi. What works is "setup.py sdist register -r wbrp upload -r wbrp" but that's kind of awful. -- ___ Python tracker <http://bugs.python.org/issue17144> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
