Martin v. Loewis wrote:
> Walter Dörwald <walter@livinglogic.de> writes:
>
>>OK, so we probably need a reverse mapping for common_types too, but
>>shouldn't we consider common_types to be fixed?
>
> If anything, types_map should be fixed: Those are the official
> IANA-supported types (including the official x- extension mechanism).
>
> The common types are those that violate IANA specs, yet found in real
> life.
>
> If you wanted to support strictness in add_type, then you would
> require that the type starts with x-; since mimetypes.py should have
> all registered types incorporated (if it misses some, that's a bug).
OK, but then adding the entries to types_map must be done differently.
I'd prefer if both can be done by add_type (but then we'd need tree
modes: Initialising types_map, adding further mappings to types_map
(checking that only x- types/subtypes are used, and adding mappings
to common_types.
>>Even better would be, if we could assign priorities to the mappings,
>>so that for e.g. image/jpeg the preferred extension is .jpeg.
>>Then guess_type() and guess_extension() would return the preferred
>>mimetype/extension.
>
>
> Do you have a specific application for that in mind? It sounds like
> overkill.
I'm using a web mirror script which uses the extensions from
guess_extension to save all downloaded resources, and I hate it
when the HTML files are named .htm and JPEG images are named .jpe.
Bye,
Walter Dörwald
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4