Add mailer shorthand for mailers[DEFAULT_MAILER_ALIAS]

[Johannes Maron]

Howdy,

The new mailers interfaces is lacking a django.db.connection equivalent.
A django.mail.mailer shorthand for mailers[DEFAULT_MAILER_ALIAS] would simplify the transition away from get_connection.

I would have complained earlier during development, but I simply missed it. Only that I am migrating a project now, I realize it's inconsistent with django.db or django.cache.

Cheerio
-Joe

[Md. Saikat Islam]

Can you add more information?

I think we already support this for default(as you mentioned for default) alias:

from django.core import mail

email_list = get_notification_emails()

# Use the default mailer. You could substitute
# mail.mailers["alias"] for a specific mailer.
backend = mail.mailers.default

backend.send_messages(email_list)

So we can use .default with mailers. But all other aliases (including default) can be accessed using mail.mailers["alias"].

Check this out: ​https://docs.djangoproject.com/en/dev/topics/email/

[Mike Edmunds]

As pointed out in comment:1, django.core.mail.mailers.default returns the default mailer instance (​docs). It is ​meant to parallel django.db.connection, django.core.cache.cache, django.tasks.default_task_backend, and similar accessors.

We can't create a module-level accessor like django.core.mail.default_mailer, because Django's ConnectionProxy and LazyObject helpers (used for module-level accessors) require cacheable instances. In general, EmailBackend instances ​are not cacheable.

[Johannes Maron]

Is it worth making the same path available on other connection proxies?
For example: django.db.connections.default, django.cache.caches.default, ...

The purpose of this DEP was consistency, right? My confusion may be an indicator that there's still some work to be done. And I pride myself on knowing Django somewhat well. Newcomers might have an even harder time understanding this.

[Mike Edmunds]

Replying to Johannes Maron:

Is it worth making the same path available on other connection proxies?
For example: django.db.connections.default, django.cache.caches.default, ...

I like that idea. (And then maybe eventually deprecating the module-level lazy proxies.)

It might be better to open a separate ticket specifically for that request, to avoid confusion.

[Johannes Maron]

I'll pass it down the proper channels then :)

[Johannes Maron]

​https://github.com/django/new-features/issues/209