This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients a.badger, barry, dhess, l0nwlf, martin.panter, pitrou, r.david.murray, siona, sivert, terry.reedy, wichert, wodny
Date 2017-05-09.00:16:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I understand hash randomization was added after this bug was opened. Here is a demonstration with “video/mp4”, which only has the extension “.mp4” built in. But my /etc/mime.types file lists “mp4 mp4v mpg4”, so after the second initialization the behaviour changes:

PYTHONHASHSEED=0 python3.5 -c 'from mimetypes import *; print(guess_all_extensions("video/mp4")); init(); print(guess_all_extensions("video/mp4"))'
['.mp4', '.mp4v', '.mpg4']
['.mpg4', '.mp4', '.mp4v']

The first extension is always “.mp4”, regardless of hash randomization, due to the built-in list. But after re-initialization, the first extension depends on the order in the internal dictionary.

Using an ordered dictionary may work as a bug fix, but the whole initialization logic is so complex and it would be good to simplify it in the long term.
Date User Action Args
2017-05-09 00:16:15martin.pantersetrecipients: + martin.panter, barry, terry.reedy, pitrou, wichert, a.badger, r.david.murray, siona, l0nwlf, wodny, sivert, dhess
2017-05-09 00:16:15martin.pantersetmessageid: <>
2017-05-09 00:16:15martin.panterlinkissue4963 messages
2017-05-09 00:16:13martin.pantercreate