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

[Stephen J. Turnbull]

Scott Dial writes:
 > 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.

There's really only one way to fairly objectively resolve this:
"Behavior that varies from documented behavior is a bug."  Everything
else is a feature request, including requests for addition of as-yet
undocumented behavior that is quite exactly analogous to existing
behavior.

Of course you can also play games with the definition of
"documentation".  If the BDFL says that his Original Intent was that
behavior X be supported, I suppose that's Sufficiently Well-Documented
(and due to the time machine Always Has Been).  Or there may be a
blanket statement that "we will conform to the version of external
standard Y that is current / draft / whatever when x.y.0 is released,"
made by the maintainer of the module on python-dev in 1999.

What does the documentation say?

On a separate issue:

 > 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.

Is it?  Maybe Microsoft has cleaned up their act, but my experience
with their IANA assignments is that there's no reliable behavior
documented by them -- the registration documents point at internal
Microsoft documents that change over time.  For example, they added
the EURO SYMBOL to several registered MIME charsets without updating
the IANA registrations.  I don't consider a registration that points
to a internal corporate document with variable content to be a
suitable specification for open source implementation, even if the
IANA can be brib^H^H^H^Hfooled into accepting a registration.

 > 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.

Features that you can't see how they could ever harm anyone are the
cracker's favorite back door.  Entries in the IANA list enable
arbitrarily complex behavior.

 > 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).

That's precisely why Python should not change this, flipped around.  A
site that carefully controls what's in mime.types should not have to
worry about Python changing types_map behind its back in a patch
release.

The right thing to do is to provide a module that allows the user to
request update of the databases automatically, and document how to do
it by hand for users who are differently abled net-wise.