New submission from R. David Murray: In issue 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). ---------- components: email keywords: easy messages: 200128 nosy: barry, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Add a datatype to represent mime types to the email module type: enhancement versions: Python 3.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19280> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
