[Python-Dev] [Python-checkins] cpython (3.2): #5301: add image/vnd.microsoft.icon (.ico) MIME type

[Scott Dial]

On 8/21/2011 3:12 PM, Terry Reedy wrote:
> On 8/21/2011 5:09 AM, Sandro Tosi wrote:
>> I can see your point: the reason I committed it also on the stable
>> branches is that .ico are already out there (since a long time) and
>> they were currently not recognized. I can call it a bug.
> 
> But it is not (a behavior bug). Every feature request 'fixes' what its
> proposer considers to be a design bug or something.

What's the feature added? That's a semantic game.

> 
>> Anyhow, if it was not appropriate, just tell me and I'll revert on 2.7
>> and 3.2 . Thanks for your input!
> 
> It is a new feature for the same reason
> http://bugs.python.org/issue10730 was. If that had not been added for
> 3.2.0 (during the beta period, with Georg's permission), it would have
> waited for 3.3.s

ISTM, that Issue #10730 was more contentious because it is *not* an
IANA-assigned mime-type, whereas image/vnd.microsoft.icon is and has
been since 2003. Whereas image/svg+xml didn't get approved until earlier
this month, AFAICT.

> Our intent is that the initial CPython x.y.0 release 'freeze' the
> definition of Python x.y. Code that were to use the new feature in 3.2.3
> would not work in 3.2.0,.1,.2, making 3.2.3 define a slight variant.
> People who want the latest version of an stdlib module should upgrade to
> the latest release or even download from the repository. For mimetypes,
> the database can be explicitly augmented in the code and then the code
> would work in all 2.7 or 3.2 releases.

Doesn't that weaken your own argument that changing the list in
Lib/mimetypes.py doesn't violate the freeze? Considering that the
mime-types are automatically read from a variety of out-of-tree
locations? It's already the case that the list of mime-types recognized
by a given CPython x.y.z is inconsistent from platform-to-platform and
more importantly installation-to-installation (since /etc/mime.types
could be customized by a given distribution or modified by a local
administrator, and on Windows, the mime-types are scrapped from the
registry).

On any reasonable system that I can get access to at the moment (Gentoo,
OS X, Win7), '.ico' is already associated with 'image/x-icon' via either
scrapping the /etc/mime.types or the registry. I think this issue
probably originates with CPython 2.6 on Windows, where there was no help
from the registry or external mime.types file.

Nevertheless, I am +0 for adding entries from the IANA list into stable
versions because I don't see how they could ever harm anyone. Any robust
program would need to be responsible and populate the mimetypes itself,
if it depended on them, otherwise, all bets are off about what types_map
contains from run-to-run of a program (because /etc/mime.types might
have changed).

-- 
Scott Dial
scott at scottdial.com