Re: Proposal to upgrade django.core.mail to Python's modern email API

[Ronny V.]

Hi all!

Jakob Rief pointed this discussion out to me. I've been going around lately 
to make some advertisement for my idea of class-based emails.

I've implemented a package called "django-pony-express" which in a nutshell 
provides to things:

* A class-based way of creating new emails (very similar to class-based 
views)
* A test suite for easy unit-testing of emails (we are currently working on 
bringing this to Django core)

Here's a documentation link: 
https://django-pony-express.readthedocs.io/en/latest/features/introduction.html#create-a-single-email
 


The idea is to create emails like you create views. All important stuff is 
encapsulated but you can overwrite everything you need. There are a bunch 
of examples in the docs.

Apart from not having to deal with low-level email API stuff (which is a 
pain IMHO), it provides lots of neat improvements I had to (re-)invent in 
every project I was working on.

What do you people think about this? I got quite good feedback in Vigo and 
in my opinion, the solution is very Django-esque.

I'd be happy to go into more detail if required but wanted to keep this 
first commend brief.

Best from Cologne
Ronny
Mike Edmunds schrieb am Montag, 24. Juni 2024 um 21:14:47 UTC+2:

> > Would this be designed to be compatible with "Proposal 14: Background 
> Workers"?
>
> I wouldn't expect this to impact background workers one way or the other. 
> The same goes for the async email proposal(s) floating around.
>
> Virtually all of this work would occur in django.core.mail.message, where 
> Python's `email` APIs are used. A goal is to avoid changes that would break 
> existing email backends (Django or third-party).
>
> The background workers proposal will implement a new background SMTP 
> EmailBackend (in django.core.mail.backends). The existing SMTP EmailBackend 
> doesn't directly use Python's `email` APIs, and there should be no reason 
> for background SMTP to be any different. (It might be helpful to know that 
> Python's `email` library isn't involved in *sending* email; that's 
> handled by Python's `smtplib`, which Django uses only in the SMTP 
> EmailBackend.)
>
> The existing SMTP EmailBackend *does* use one function I expect will 
> become deprecated: django.core.mail.message.sanitize_address(). I haven't 
> yet investigated whether that use is still necessary, or whether it's there 
> to get around past bugs/limitations in Python's smtplib. If any of it is 
> still needed for SMTP, I'd probably want to move that code into the SMTP 
> EmailBackend(s).
>
> - Mike
> On Sunday, June 23, 2024 at 10:22:03 PM UTC-7 Arthur Pemberton wrote:
>
>> Would this be designed to be compatible with "Proposal 14: Background 
>> Workers"?
>>
>>
>>
>> On Sun, Jun 23, 2024 at 10:46 PM Mike Edmunds  wrote:
>>
>>> I want to propose updating django.core.mail to replace use of Python's 
>>> legacy email.message.Message (and other legacy email APIs) with 
>>> email.message.EmailMessage (and other modern APIs).
>>>
>>> If there's interest, I can put together a more detailed proposal and/or 
>>> ticket, but was hoping to get some initial feedback first. (I searched for 
>>> relevant discussions in django-developers and the issue tracker, and didn't 
>>> find any. Apologies if this has come up before.)
>>>
>>> [Note: I maintain django-anymail 
>>> , which implements Django 
>>> integration with several transactional email service providers.]
>>>
>>>
>>> *Background*
>>>
>>> Since Python ~3.6, Python's email package has included two largely 
>>> separate implementations:
>>>
>>>- a "modern (unicode friendly) API" based on 
>>>email.message.EmailMessage and email.policy.default
>>>- a "legacy API" providing compatibility with older Python versions, 
>>>based on email.message.Message and email.policy.compat32
>>>
>>> (See https://docs.python.org/3/library/email.html, especially toward 
>>> the end.)
>>>
>>> django.core.mail currently uses the legacy API.
>>>
>>>
>>> *Why switch?*
>>>
>>> There are no plans to deprecate Python's legacy email API, and it's 
>>> working, so why change Django?
>>>
>>>- 
>>>
>>>*Fewer bugs:* The modern API fixes a *lot* of bugs in the legacy 
>>>API. My understanding is legacy bugs will generally not be fixed. (And 
>>> in 
>>>fact, there are some cases where the legacy API deliberately replicates 
>>>earlier buggy behavior.)
>>>
>>>Django #35497  is an 
>>>example of a legacy bug (with a problematic proposed workaround) which 
>>> is 
>>>just fixed in the modern API.
>>>- 
>>>
>>>*Simpler, safer code:* A substantial portion 
>>>
>>> 
>>>  of 
>>>django.core.mail's internals implements workarounds and security fixes 
>>> for 
>>>problems in the legacy API. This would be greatly simplified—maybe 
>>>elim

Re: Proposal to upgrade django.core.mail to Python's modern email API

[Ronny V.]

Adding my support for the suggested approach. Start small and central and 
step-by-step. 👍

> (I'm going to add a link in django-anymail's "you probably don't need 
proprietary ESP templates 
" docs.) 

Thanks! Much appreciated!

And thx on your thoughts about the class-based emails. I do agree that we 
should start with the proposed changes. Then we'll worry about the 
high-level stuff.

Best regards from Cologne
Ronny

PS: Sorry for misspelling Jacob Rief in my earlier posting!


Florian Apolloner schrieb am Freitag, 28. Juni 2024 um 22:07:35 UTC+2:

> Hi Mike,
>
> overall the plan sounds good. I especially like the approach to "fix" the 
> tests first. This can happen in an extra merge request and reviewed 
> independently so we can be sure that we are still testing what we want to 
> test before moving to the tricky parts.
>
> On Thursday, June 27, 2024 at 3:28:06 AM UTC+2 Mike Edmunds wrote:
>
>
>1. 
>
>Deprecate unused internal APIs from django.core.mail.message
>
>Django will no longer need these (Python's modern email API covers 
>their functionality), but they may be in use by third-party libraries:
>- utf8_charset
>   - utf8_charset_qp
>   - RFC5322_EMAIL_LINE_LENGTH_LIMIT
>   - BadHeaderError^ (more details below)
>   - ADDRESS_HEADERS
>   - forbid_multi_line_headers()^
>   - sanitize_address() (more details below)
>   - MIMEMixin
>   - SafeMIMEMessage
>   - SafeMIMEText^
>   - SafeMIMEMultipart^
>
>(Items marked ^ are exposed in django.core.mail via __all__. I haven't 
>looked into the reason for that.)
>
>
> Are all of those documented? If not we can simply remove them (especially 
> if the deprecation implementation turns out to be a PITA).  
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b8d51b07-321b-4540-8188-46cd0b9a711fn%40googlegroups.com.