#35728: Lazily compute assertion messages
--------------------------------------+------------------------------------
Reporter: Adam Johnson | Owner: (none)
Type: Cleanup/optimization | Status: new
Component: Testing framework | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by Adam Johnson):
Nice benchmarking idea. Looks like we may be able to trim the overhead
further.
For reference, `assertIn` avoids the overhead by performing the test
first:
https://github.com/python/cpython/blob/fbb26f067a7a3cd6dc6eed31cce12892cc0fedbb/Lib/unittest/case.py#L1178-L1183
I think we should be able to adopt that pattern too. No need for a lazy
string, really.
> Accepting following the above with the note that we should, ideally, be
mindful of potential subclassing of Django's TestCase when designing how
the laziness will be incorported to ensure backwards compatibility.
Sure, but I don’t think we don’t need to support, say, an overridden
`_assert_contains`, because that’s the private method under the public
`assertContains`.
--
Ticket URL: <https://code.djangoproject.com/ticket/35728#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/01070191b3ce4bef-71f96cb4-beb8-41da-b415-b4bc1cde1b2a-000000%40eu-central-1.amazonses.com.
