There are a few places in the new email API where dicts are returned containing what is conceptually static information.  Currently this is done by returning a copy of the dict from the object, so that user code modifying the dict won't break the object invariants.  It would be better to change these to MappingProxyType objects instead, before the API moves out of provisional status.

This issue is mostly a note to myself, since I'm the most likely to be able to figure out which places in the code need changing, but if anyone else wants to look at it feel free, since it will probably be a while before I get to it.

Hi David, I can take this on as I am learning the email api currently.

David,

do you have an example, I am at the CPython sprint in Dublin, and I think I can work on this issue.

Thanks

The principle example is the 'params' dictionary in headerregistry.  Currently it gets recreated every time you access that attribute.  You can *apparently* change it, but that has no real effect.  Probably the computed value should be cached the first time the attribute is accessed, and a MappingProxy over the cached value returned.

Hi David,

I didn't find an other example of a copy(dict), the rest is just some lists. If you have an other example in the email library, I will agree to provide an other patch.

In fact, I am really dubious with my patch because this one is really small and I think there is a missing part somewhere because the description of this issue takes 4 lines and the patch only 2.

Here is the new version of this patch with a test.

No, it looks fine.  This issue was mostly a reminder to myself.  Thanks for the patch.

The other place I thought there might be some instances of this was in _header_value_parser, but I don't see any on a quick scan.  So this may be it.

Tell me if you will review this patch and maybe accept it ;-)

In fact I checked all the return keywords in the email library and I didn't find any other copy of a dict.

This is the reason why I am dubious about my patch ;-)

New version of the patch

sorry, but how to update a patch without losing the rietveld review? Is there a documentation about that?

Thanks.

Stephane

> sorry, but how to update a patch without losing the rietveld review?

I see 3 patch sets at:
http://bugs.python.org/review/21991/

No review is lost when you remove a patch. But it's better to attach a new patch with a different name. I like the name pattern: name.patch, name-2.patch, name-3.patch, etc. It's easier to refer to a patch when it has a unique name.

issue21991.patch looks good to me. I didn't check if more methos should be modified. David knows that better than me :-)

Personally I would test that the returned object is read only, rather than checking for MappingProxyType explicitly, but you can argue either way as being better :)

As for other occurrences, I must have been either misremembering, or I refactored the other occurrences out of existence earlier.

Yes I will apply this.

> Personally I would test that the returned object is read only

I agree: write a short helper to check that modifying the dict fails.

New changeset fea3ddcaf652 by R David Murray in branch '3.4':
#21991: make headerregistry params property MappingProxyType.
https://hg.python.org/cpython/rev/fea3ddcaf652

New changeset 5beb1ea76f36 by R David Murray in branch 'default':
Merge: #21991: make headerregistry params property MappingProxyType.
https://hg.python.org/cpython/rev/5beb1ea76f36

Thanks, Stéphane.  I committed the fix with a modified test.

Thanks David,