Re: [Python-Dev] standard library mimetypes module pathologically broken?

Brett Cannon wrote:
>>>> Â* It creates a _default_mime_types() function which declares a
>>>> Â Âbunch of global variables, and then immediately calls
>>>> Â Â_default_mime_types() below the definition. There is literally
>>>> Â Âno difference in result between this and just putting those
>>>> Â Âvariables at the top level of the file, so I have no idea why
>>>> Â Âthis function exists, except to make the code more confusing.
>>>
>>> It could potentially be used for testing, but that's a guess.
>>
>> Here's an abridged version of this function. I donât think thereâs any
>> reason for this that I can see.
>>
>> Â Âdef _default_mime_types():
>> Â Â Â Âglobal suffix_map
>> Â Â Â Âglobal encodings_map
>> Â Â Â Âglobal types_map
>> Â Â Â Âglobal common_types
>>
>> Â Â Â Âsuffix_map = {
>> Â Â Â Â Â Â'.tgz': '.tar.gz', #...
>> Â Â Â Â Â Â}
>>
>> Â Â Â Âencodings_map = {
>> Â Â Â Â Â Â'.gz': 'gzip', #...
>> Â Â Â Â Â Â}
>>
>> Â Â Â Âtypes_map = {
>> Â Â Â Â Â Â'.a' Â Â Â: 'application/octet-stream', #...
>> Â Â Â Â Â Â}
>>
>> Â Â Â Âcommon_types = {
>> Â Â Â Â Â Â'.jpg' : 'image/jpg', #...
>> Â Â Â Â Â Â}
>>
>> Â Â_default_mime_types()
>
> As R. David pointed out, it is being used by regrtest to clean up after
> running the test suite.

Yeah, basically the issue is that the default mime types should be
separate objects from the final set after apache's files have been
parsed and custom additions have been made. If these ones at the top
level are renamed and not modified after creation, if new objects with
all the updated stuff is put at these names, and if the test code is
changed to instead reset the ones at these names based on the default
objects, I think that will maybe fix things.  I'll try to write some
potential patches in the next day or two and submit them here for
advice.

>> The problem is that the semantics as documented are really ambiguous,
>> and what I would consider the reasonable interpretation is different
>> from what the code actually does. So anyone using this code naively is
>> going to run into trouble, and anyone relying on how the code actually
>> works is going behind the back of the docs, but they sort of have to
>> in order to use much of the functionality of the module. I agree this
>> puts us in a tricky spot.
>
> Well, perhaps the docs can be updated to match the code where cleanup would
> change the semantics.

I think that would make the docs extremely confusing, and Iâm not even
sure it would be possible. The current semantics are vaguely okay if
an API consumer sticks to straight-forward use cases, such as any
which donât break when the current docs are followed (anything
complicated is going to break unless the code is read a few times),
and assuming such uses it would be possible to swap out most of the
implementation for something relatively straight-forward. But if any
of the edges are pushed, the semantics quickly turn insane, to the
point Iâm not sure theyâre document-able. Anyone expecting the code to
work that way is going to have a buggy program anyway, so Iâm not sure
it makes sense to bend over backwards leaving the particular set of
bugs unchanged.

Cheers,
Jacob Rus
_______________________________________________
Python-Dev mailing list
Python-Dev@xxxxxxxxxx
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/maillists%40codeha.us