Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a datatype to represent mime types to the email module #63479

Open
bitdancer opened this issue Oct 17, 2013 · 3 comments
Open

Add a datatype to represent mime types to the email module #63479

bitdancer opened this issue Oct 17, 2013 · 3 comments
Labels
easy expert-email type-feature A feature request or enhancement

Comments

@bitdancer
Copy link
Member

bitdancer commented Oct 17, 2013

BPO 19280
Nosy @warsaw, @pitrou, @ezio-melotti, @bitdancer, @vadmium

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2013-10-17.14:13:03.506>
labels = ['easy', 'type-feature', 'expert-email']
title = 'Add a datatype to represent mime types to the email module'
updated_at = <Date 2014-09-05.23:52:54.511>
user = 'https://github.com/bitdancer'

bugs.python.org fields:

activity = <Date 2014-09-05.23:52:54.511>
actor = 'martin.panter'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['email']
creation = <Date 2013-10-17.14:13:03.506>
creator = 'r.david.murray'
dependencies = []
files = []
hgrepos = []
issue_num = 19280
keywords = ['easy']
message_count = 3.0
messages = ['200128', '200265', '200638']
nosy_count = 5.0
nosy_names = ['barry', 'pitrou', 'ezio.melotti', 'r.david.murray', 'martin.panter']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue19280'
versions = ['Python 3.5']

@bitdancer
Copy link
Member Author

bitdancer commented Oct 17, 2013

In bpo-18891, Stephen Turnbull wondered if adding a datatype to represent mime types would be worthwhile.

I think it would be. A mimetype is a pair (maintype/subtype), and while one may test the subparts independently in logic, the representation and what needs to be passed from place to place in the code is always a pair. Most importantly, having a datatype to represent this would eliminate a common class of errors: forgetting to test the component strings case-insensitively. If one is manipulating a Message object, the get_xxx methods used to access the mimetype do do case coercion, but within the email code itself there are a number of places where the raw strings are manipulated, and I have already made, discovered, and fixed case insensitivity bugs in that code.

It is not clear at this point if the object should be exposed, though I'm inclined that way. I'd propose using a string subclass with maintype and subtype attributes, and this object could then be returned by get_content_type without breaking backward compatibility. Another advantage of using a string subclass is that the original casing of the values is easily retained and easily accessible, which while not critical is something the email package normally does (preserve the case of the original data).

@bitdancer bitdancer added expert-email easy type-feature A feature request or enhancement labels Oct 17, 2013
@pitrou
Copy link
Member

pitrou commented Oct 18, 2013

I don't know much about the email module, but FWIW I think str subclasses (or any subclass of built-in types) are a delicate thing to expose in an API. I think a namedtuple would be the more idiomatic choice here (perhaps with an appropriate __str__ for convenient conversion / %-formatting / {}-formatting).

@bitdancer
Copy link
Member Author

bitdancer commented Oct 20, 2013

Well, it's about backward compatibility, and the email module already uses str subclasses for headers in the new code, for backward compatibility reasons. I hope this does not prove fragile in practice, but I have no way of knowing for sure, of course.

It occurs to me, however, that the (new) content-type header's value already has the maintype/subtype attributes, so there's really no need to change the return type of the get_content_type method.

For internal use...a named tuple is not adequate, since I need to preserve the original case of the values.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
easy expert-email type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants