fix: accept message string in error and warning constructors

[zlalvani]

fixes #271

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.44%. Comparing base (1cebd3f) to head (5d395ef).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #272   +/-   ##
=======================================
  Coverage   98.44%   98.44%           
=======================================
  Files          19       19           
  Lines         771      771           
  Branches       83       83           
=======================================
  Hits          759      759           
  Misses         10       10           
  Partials        2        2           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mcous]

Thanks for getting this issue resolved! Since we have multiple Warning and Exception classes with overloaded __init__ methods, I like your idea of a more robust fix, since good pytest-xdist support is important to me.

Can you apply the following suggestion to all our Warning and Exception classes that have custom __init__ methods defined? This will (hopefully obviously) also require updating some call sites

[mcous]

suggestion: rather than overload the constructor, let's make a larger change:

• Add a create classmethod with the same signature as the old constructor, taking the rehearsal
• Remove __init__, allowing it to use the default warning constructor

That way, our creation and (de)serialization both use the same string-based constructor, while message generation logic that relies on internal interfaces is split out to our own bespoke method

[zlalvani]

@mcous The constructors are currently being used to set properties on the warning classes that appear to be used for testing, should I omit that? If I don't, the constructor can't take the standard parameters

[mcous]

Oh right, good catch. The fact that they're relied upon in tests is an oversight and something I'm not particularly worried about maintaining. Use your best judgement to update tests if needed and I can fix anything up prior to merge.

The thing I am concerned about: removing those properties would technically be a breaking change. I am removing them in the next major version, so does something a little silly like this work to keep them for now?

class SomeWarning():
    @classmethod
    def create(cls, calls: ...):
        message = ...
        result = cls(message)
        result.calls = calls
        ...

        return result

[mcous]

Oh also let me know if this is more effort than you want to / are available to take on! I really appreciate the work you've already done to observe and identify the issue