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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
