S
Sion Arrowsmith
ge = mimetypes.guess_extension
I actually discovered this through explicitly calling mimetypes.init
to reload an edited mime.types file between calls to guess_extension,
but I think the above scenario makes for more disturbing reading
The problem is that mimetools initialises its type mapping dict
before adding new type mappings from a file by iterating through the
existing type mapping dict. This process is bootstrapped by a hard-
coded dict which gets shadowed by the first file read, so the second
file read uses a dict initialsed from the dict created by the first
file read (got that?) which has a different iteration order to the
hard-coded dict. So the mappings get added in a different order the
second time around, and where there are multiple mappings like this
you get a different answer.
Is this a bug? If I want to be sure of a consistent result, do I
need to use sorted(mimetools.guess_all_extensions(t))[0] (or [-1])?
I actually discovered this through explicitly calling mimetypes.init
to reload an edited mime.types file between calls to guess_extension,
but I think the above scenario makes for more disturbing reading
The problem is that mimetools initialises its type mapping dict
before adding new type mappings from a file by iterating through the
existing type mapping dict. This process is bootstrapped by a hard-
coded dict which gets shadowed by the first file read, so the second
file read uses a dict initialsed from the dict created by the first
file read (got that?) which has a different iteration order to the
hard-coded dict. So the mappings get added in a different order the
second time around, and where there are multiple mappings like this
you get a different answer.
Is this a bug? If I want to be sure of a consistent result, do I
need to use sorted(mimetools.guess_all_extensions(t))[0] (or [-1])?