Scott David Daniels <[EMAIL PROTECTED]> writes:
> I would rather something more like:
>
> def assert_compare_true(op, first, second, msg=None):
> if op(first, second):
> return
> raise self.failure_exception(msg)
> if msg is None:
> self.failure_exception("%(first)r %(op)r %(second)"
> % vars())
> self.failure_exception("%(first)r %(op)r %(second): %(msg)"
> % vars())
I'm confused. It appears to me that your version never gets past the
first 'raise' statement, which is unconditional; and the rest seems to
do nothing but instantiate exceptions without using them.
Do you perhaps mean something like this::
def assert_compare_true(op, first, second, msg=None):
fail_detail = "%(first)r %(op)r %(second)r" % vars()
if msg is None:
msg = fail_detail
else:
msg = "%(fail_detail)s: %(msg)s" % vars()
if not op(first, second):
raise self.failure_exception(msg)
If so, that sems to be in line with the "Enhanced failure message"
principle exercised elsewhere in the same PEP, i.e. that the failure
message should *always* contain certain information, even if a message
is specified by the caller.
One downside I can see is that, in optimising for this common case, it
makes the function useless to someone who wants to specify their own
failure message exactly, without the specific extra information in
that specific format.
What do others think of this?
--
\ “Holy contributing to the delinquency of minors, Batman!” —Robin |
`\ |
_o__) |
Ben Finney
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
