| 15 | | B. Can we require that (Django's built-in) EmailBackend instances ''must'' be obtained by calling mail.get_connection(), or do we need to continue allowing code to construct them directly? |
| 16 | | [[BR]][[BR]]If we can require get_connection(), it simplifies the backwards compatibility code in each EmailBackend somewhat. But it requires updating nearly all of Django's existing EmailBackend tests, which tend to call the constructor directly. (The current PR includes most of those test updates; we'd likely want to pull them into a separate "refs" commit first to prove they run correctly before this change.) |
| 17 | | [[BR]][[BR]]The relevant docs start at [https://docs.djangoproject.com/en/6.0/topics/email/#obtaining-an-instance-of-an-email-backend Obtaining an instance of an email backend]: "The `get_connection()` function in `django.core.mail` returns an instance of the email backend that you can use." But they go on to document available options for backends.smtp.EmailBackend() using the class constructor format. |
| 18 | | [[BR]][[BR]]I don't know whether that means we have documented smtp.EmailBackend as a class, so the constructor must remain callable for backwards compatibility. Or if it was just a convenient docutils syntax for describing SMTP EmailBackend options that can be used as keywords to get_connection(). (I can't imagine why real-world code would want to call an EmailBackend constructor directly rather than going through get_connection().) |
| | 15 | B. ~~Can we require that (Django's built-in) EmailBackend instances ''must'' be obtained by calling mail.get_connection(), or do we need to continue allowing code to construct them directly?~~ |
| | 16 | [[BR]][[BR]]~~If we can require get_connection(), it simplifies the backwards compatibility code in each EmailBackend somewhat. But it requires updating nearly all of Django's existing EmailBackend tests, which tend to call the constructor directly. (The current PR includes most of those test updates; we'd likely want to pull them into a separate "refs" commit first to prove they run correctly before this change.)~~ |
| | 17 | [[BR]][[BR]]~~The relevant docs start at [https://docs.djangoproject.com/en/6.0/topics/email/#obtaining-an-instance-of-an-email-backend Obtaining an instance of an email backend]: "The `get_connection()` function in `django.core.mail` returns an instance of the email backend that you can use." But they go on to document available options for backends.smtp.EmailBackend() using the class constructor format.~~ |
| | 18 | [[BR]][[BR]]~~I don't know whether that means we have documented smtp.EmailBackend as a class, so the constructor must remain callable for backwards compatibility. Or if it was just a convenient docutils syntax for describing SMTP EmailBackend options that can be used as keywords to get_connection(). (I can't imagine why real-world code would want to call an EmailBackend constructor directly rather than going through get_connection().)~~ |
| | 19 | [[BR]][[BR]][Edit 2026-02-12: with the updated `mail.providers[alias]` API and related changes, I think this is no longer a concern. Tests can continue to call backend constructors directly, and should just add an `alias="anything"` arg to avoid deprecated initialization.] |