This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients barry, r.david.murray
Date 2011-03-31.18:48:58
SpamBayes Score 4.0615233e-10
Marked as misclassified No
Message-id <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
In-reply-to
Content
As part of the email6 design, the email-sig came up with the idea of simplifying the current email API by introducing the concept of "policy objects".  A policy object is an object that hold various parameters and methods that can be used to control the behavior of the email package.  Thus, instead of having 'maxheaderlen', '_mangle_from', 'unixfrom', linesep, etc, etc options, you have a policy object that holds settings for these options that are applicable to a particular domain.  Thus an 'SMTP' policy would have a maxheaderlen of 76, a linesep of \r\n, and _mangle_from and unixfrom false, while mbox would have linesep \n and _mangle_from and unixfrom True.  HTTP would be like SMTP, but with maxheaderlen 0 (unlimited).

The policy is passed to the parser and/or the generator construtor to control how input is interpreted and how output is generated.  By encapsulating the details into objects related to clearly defined problem domains, we make it much simpler to use the email package both within a domain and for translating messages between domains.

Originally we saw the policy object as fundamental to the whole email6 design, but it has become clear that it is actually a relatively independent piece, and by itself much smaller than the parser and generator changes required for the full email6 implementation.

Therefore I'm starting the email6 development with the policy object piece as a standalone proposal.  I'd like to see this piece get reviewed and committed early in the process so I can use it as an underpinning for the further work.

I've set up a feature repo for email6 at features/email6.  I've pushed the framework (the policy object and its docs, with a selection of the options I intend to implement documented) and several integration updates (raise_on_defect, linesep, must_be_7bit).  I thought I'd post this issue now, with the link to the repo, so people can give me early feedback if they wish.

Ultimately I would like to deprecate the constructor arguments that are subsumed by the policy object settings.
History
Date User Action Args
2011-03-31 18:49:00r.david.murraysetrecipients: + r.david.murray, barry
2011-03-31 18:49:00r.david.murraysetmessageid: <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
2011-03-31 18:48:59r.david.murraylinkissue11731 messages
2011-03-31 18:48:58r.david.murraycreate