Deprecating or changing how django.core.mail handles fail_silently

Django Internals
5

Hi Mike, you were on my list, sorry for not reaching out sooner! Your notes were super helpful, as I’m new to this area of Django.

Is there some use case I’m missing?

My impressions are:

  • fail_silently was used to rhyme with contrib.messages, which exposes this same argument for the use case of a reusable app (such as the admin!), that cannot guarantee that contrib.messages is installed. I see the use case for email as basically the same: I’m writing a reusable app: I’d like to send some mail, so long as my users have email configured at all.
  • I also see a use case for test suites.
  • I like that API. (I don’t think it’s a weird abstraction.)
  • Thanks for the ticket about the imprecise wording in the docs. But leaving the imprecision to the side, my impression is that once again, just like-fail-silently in contrib.messages only catching the error for the messages app not being installed, the email backends should only be catching connection errors. SMTP connection errors became a subclass of OSError in Python 3.4. I agree with generalizing the catch as far as OSError, but not further.
  • I’m unclear what we gain from the hybrid approach of deprecating the arg in some places and not others (and unclear how this unblocks the DEP).

So, in summary, I’d vote for option 1 with catching OSError.

What do you think?

1 Like