| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
(GH-595) (GH-2233)
If max_line_length=None is specified while using the Compat32 policy,
it is no longer ignored..
(cherry picked from commit b459f7482612d340b88b62edc024628595ec6337)
|
| | |
|
| |
|
|
|
|
|
| |
This defaults to True in the compat32 policy for backward compatibility,
but to False for all new policies.
Patch by Milan Oberkirch, with a few tweaks.
|
| |
|
|
|
|
|
|
|
| |
This could use more edge case tests, but the basic functionality is tested.
(Note that this changeset does not add tailored support for the RFC 6532
message/global MIME type, but the email package generic facilities will handle
it.)
Reviewed by Maciej Szulik.
|
| |
|
|
|
| |
Thanks to Nick Coghlan for pointing out that I'd forgotten about class
decorators.
|
| |
|
|
|
| |
Or perhaps more hackish, depending on your perspective. But at least this
way it is now possible to run the individual tests using the unittest CLI.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the new policies are used (and only when the new policies are explicitly
used) headers turn into objects that have attributes based on their parsed
values, and can be set using objects that encapsulate the values, as well as
set directly from unicode strings. The folding algorithm then takes care of
encoding unicode where needed, and folding according to the highest level
syntactic objects.
With this patch only date and time headers are parsed as anything other than
unstructured, but that is all the helper methods in the existing API handle.
I do plan to add more parsers, and complete the set specified in the RFC
before the package becomes stable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch primarily does two things: (1) it adds some internal-interface
methods to Policy that allow for Policy to control the parsing and folding of
headers in such a way that we can construct a backward compatibility policy
that is 100% compatible with the 3.2 API, while allowing a new policy to
implement the email6 API. (2) it adds that backward compatibility policy and
refactors the test suite so that the only differences between the 3.2
test_email.py file and the 3.3 test_email.py file is some small changes in
test framework and the addition of tests for bugs fixed that apply to the 3.2
API.
There are some additional teaks, such as moving just the code needed for the
compatibility policy into _policybase, so that the library code can import
only _policybase. That way the new code that will be added for email6
will only get imported when a non-compatibility policy is imported.
|
|
|
This new interface will also allow for future planned enhancements
in control over the parser/generator without requiring any additional
complexity in the parser/generator API.
Patch reviewed by Éric Araujo and Barry Warsaw.
|
