Source

cpython / Doc / library / email.policy.rst

Full commit

:mod:`email.policy`: Policy Objects

The :mod:`email` package's prime focus is the handling of email messages as described by the various email and MIME RFCs. However, the general format of email messages (a block of header fields each consisting of a name followed by a colon followed by a value, the whole block followed by a blank line and an arbitrary 'body'), is a format that has found utility outside of the realm of email. Some of these uses conform fairly closely to the main RFCs, some do not. And even when working with email, there are times when it is desirable to break strict compliance with the RFCs.

Policy objects give the email package the flexibility to handle all these disparate use cases.

A :class:`Policy` object encapsulates a set of attributes and methods that control the behavior of various components of the email package during use. :class:`Policy` instances can be passed to various classes and methods in the email package to alter the default behavior. The settable values and their defaults are described below.

There is a default policy used by all classes in the email package. This policy is named :class:`Compat32`, with a corresponding pre-defined instance named :const:`compat32`. It provides for complete backward compatibility (in some cases, including bug compatibility) with the pre-Python3.3 version of the email package.

The first part of this documentation covers the features of :class:`Policy`, an :term:`abstract base class` that defines the features that are common to all policy objects, including :const:`compat32`. This includes certain hook methods that are called internally by the email package, which a custom policy could override to obtain different behavior.

When a :class:`~email.message.Message` object is created, it acquires a policy. By default this will be :const:`compat32`, but a different policy can be specified. If the Message is created by a :mod:`~email.parser`, a policy passed to the parser will be the policy used by the Message it creates. If the Message is created by the program, then the policy can be specified when it is created. When a Message is passed to a :mod:`~email.generator`, the generator uses the policy from the Message by default, but you can also pass a specific policy to the generator that will override the one stored on the Message object.

:class:`Policy` instances are immutable, but they can be cloned, accepting the same keyword arguments as the class constructor and returning a new :class:`Policy` instance that is a copy of the original but with the specified attributes values changed.

As an example, the following code could be used to read an email message from a file on disk and pass it to the system sendmail program on a Unix system:

>>> from email import msg_from_binary_file
>>> from email.generator import BytesGenerator
>>> from subprocess import Popen, PIPE
>>> with open('mymsg.txt', 'b') as f:
...     msg = msg_from_binary_file(f)
>>> p = Popen(['sendmail', msg['To'][0].address], stdin=PIPE)
>>> g = BytesGenerator(p.stdin, policy=msg.policy.clone(linesep='\r\n'))
>>> g.flatten(msg)
>>> p.stdin.close()
>>> rc = p.wait()

Here we are telling :class:`~email.generator.BytesGenerator` to use the RFC correct line separator characters when creating the binary string to feed into sendmail's stdin, where the default policy would use \n line separators.

Some email package methods accept a policy keyword argument, allowing the policy to be overridden for that method. For example, the following code uses the :meth:`~email.message.Message.as_string` method of the msg object from the previous example and writes the message to a file using the native line separators for the platform on which it is running:

>>> import os
>>> with open('converted.txt', 'wb') as f:
...     f.write(msg.as_string(policy=msg.policy.clone(linesep=os.linesep))

Policy objects can also be combined using the addition operator, producing a policy object whose settings are a combination of the non-default values of the summed objects:

>>> compat_SMTP = email.policy.clone(linesep='\r\n')
>>> compat_strict = email.policy.clone(raise_on_defect=True)
>>> compat_strict_SMTP = compat_SMTP + compat_strict

This operation is not commutative; that is, the order in which the objects are added matters. To illustrate:

>>> policy100 = compat32.clone(max_line_length=100)
>>> policy80 = compat32.clone(max_line_length=80)
>>> apolicy = policy100 + Policy80
>>> apolicy.max_line_length
80
>>> apolicy = policy80 + policy100
>>> apolicy.max_line_length
100

This is the :term:`abstract base class` for all policy classes. It provides default implementations for a couple of trivial methods, as well as the implementation of the immutability property, the :meth:`clone` method, and the constructor semantics.

The constructor of a policy class can be passed various keyword arguments. The arguments that may be specified are any non-method properties on this class, plus any additional non-method properties on the concrete class. A value specified in the constructor will override the default value for the corresponding attribute.

This class defines the following properties, and thus values for the following may be passed in the constructor of any policy class:

The following :class:`Policy` method is intended to be called by code using the email library to create policy instances with custom settings:

The remaining :class:`Policy` methods are called by the email package code, and are not intended to be called by an application using the email package. A custom policy must implement all of these methods.

This concrete :class:`Policy` is the backward compatibility policy. It replicates the behavior of the email package in Python 3.2. The :mod:`policy` module also defines an instance of this class, :const:`compat32`, that is used as the default policy. Thus the default behavior of the email package is to maintain compatibility with Python 3.2.

The class provides the following concrete implementations of the abstract methods of :class:`Policy`:

Note

The documentation below describes new policies that are included in the standard library on a :term:`provisional basis <provisional package>`. Backwards incompatible changes (up to and including removal of the feature) may occur if deemed necessary by the core developers.

This concrete :class:`Policy` provides behavior that is intended to be fully compliant with the current email RFCs. These include (but are not limited to) RFC 5322, RFC 2047, and the current MIME RFCs.

This policy adds new header parsing and folding algorithms. Instead of simple strings, headers are custom objects with custom attributes depending on the type of the field. The parsing and folding algorithm fully implement RFC 2047 and RFC 5322.

In addition to the settable attributes listed above that apply to all policies, this policy adds the following additional attributes:

The class provides the following concrete implementations of the abstract methods of :class:`Policy`:

The following instances of :class:`EmailPolicy` provide defaults suitable for specific application domains. Note that in the future the behavior of these instances (in particular the HTTP instance) may be adjusted to conform even more closely to the RFCs relevant to their domains.

With all of these :class:`EmailPolicies <.EmailPolicy>`, the effective API of the email package is changed from the Python 3.2 API in the following ways:

  • Setting a header on a :class:`~email.message.Message` results in that header being parsed and a custom header object created.
  • Fetching a header value from a :class:`~email.message.Message` results in that header being parsed and a custom header object created and returned.
  • Any custom header object, or any header that is refolded due to the policy settings, is folded using an algorithm that fully implements the RFC folding algorithms, including knowing where encoded words are required and allowed.

From the application view, this means that any header obtained through the :class:`~email.message.Message` is a custom header object with custom attributes, whose string value is the fully decoded unicode value of the header. Likewise, a header may be assigned a new value, or a new header created, using a unicode string, and the policy will take care of converting the unicode string into the correct RFC encoded form.

The custom header objects and their attributes are described in :mod:`~email.headerregistry`.