New submission from R. David Murray rdmur...@bitdance.com:
As discussed in my email to python-dev, I'm planning to add the new header
parsing to Python 3.3 as a provisional extension, by adding a (set) of policies
that are clearly marked provisional in the documentation. In order for this to
work, I first need to make certain enhancements to the Policy framework that I
previously committed to default.
When reviewing the patch, please start with the 'architecture.rst' file in the
Lib/email directory, which provides an overview of the changes and the plan.
The primary changes are to add some new policy hooks that feedparser, message,
and generator call. These hooks are then implemented on the renamed default
policy (now called 'compat32') in such a way as to replicate the behavior of
Python 3.2. The other significant change is that Message objects now have a
policy. In order to accommodate this, this patch adds 'policy propagation'
logic. That is, if you pass a policy to feedparser, then all the Message
objects it creates get that policy. And when you flatten a message with a
Generator, it uses the policy attached to the message unless you explicitly
override it.
I also factored policy into _basepolicy.py and policy.py. This doesn't mean
much for this patch, but when the new policies land they go in policy.py, while
the default policy is imported from _policybase. This means that if a Python
3.3 program does not explicitly use a policy, it will not import any of the new
code.
The remaining changes in the patch are some test reorganization. Since the
goal is now 100% backward compatibility with Python 3.2 (including bugs in some
cases), the patch removes some tests that were previously added to
test.test_email.test_email and puts them into module specific test files
(test_generator, test_parser, test_policy). Additional tests are also added.
The end result of the test refactoring is that if you diff test_email.py after
this patch against the 3.2 test_email.py, you should find a few places where
the scaffolding is changed and the addition of some tests for bug fixes in the
3.2 code. Otherwise the tests should be identical to 3.2, with all the policy
related tests moving into test_policy.
The longer term plan for this is to replicate all of the test_email.py tests in
appropriate module-specific test files (I've already marked a few such tests
that got replicated in test_policy). By the time we get to Python4 the plan is
for all the tests to be replicated, so that we can at that point drop compat32
by removing the policy and the test_email.py test file, as well as the code
that will be at that point obsolete.
The primary review here should be to make sure I am in fact producing 100%
backward compatibility. Any other review comments will be welcome, of course.
PS: I also changed the 'must_be_7bit' policy control, whose name I never liked,
to be 'cte_type', which can be '7bit' or '8bit'. As noted in the
architecture.rst file, the extra motivation for this is that there will
eventually be a 'cte_type=unicode' which will support unicode display of
formatted messages and, perhaps even more important, rfc 5335.
--
hgrepos: 121
messages: 160015
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Enhance Policy framework in preparation for adding eamil6 policy as
provisional
type: enhancement
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14731
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
