Re: [Python-Dev] [Python-checkins] cpython (3.2): #5301: add image/vnd.microsoft.icon (.ico) MIME type
Hi, However small the commit was, I think it still was a feature request, so I wonder if it was appropriate for the stable versions. Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot failures
Le 20/08/2011 22:52, Paul Moore a écrit : > My buildbot seems to have been failing for a while (I've been away on > holiday) - http://www.python.org/dev/buildbot/buildslaves/moore-windows > > The failures seem to generally be in distutils and/or packaging. I see > quite a lot of reds in the waterfall display at the moment, and I > can't see any particular issue with my buildbot, so before I go > digging further, can anyone confirm (or otherwise) if > distutils/packaging is currently generating known failures (and hence, > the alerts can be ignored? Yes: http://bugs.python.org/issue12678 Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): #5301: add image/vnd.microsoft.icon (.ico) MIME type
Hi, On Sun, Aug 21, 2011 at 10:17, Éric Araujo wrote: > Hi, > > However small the commit was, I think it still was a feature request, so > I wonder if it was appropriate for the stable versions. 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. Anyhow, if it was not appropriate, just tell me and I'll revert on 2.7 and 3.2 . Thanks for your input! Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): #5301: add image/vnd.microsoft.icon (.ico) MIME type
On 8/21/2011 5:09 AM, Sandro Tosi wrote: However small the commit was, I think it still was a feature request, so I wonder if it was appropriate for the stable versions. Good catch. 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. 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 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. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): #5301: add image/vnd.microsoft.icon (.ico) MIME type
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 [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): #5301: add image/vnd.microsoft.icon (.ico) MIME type
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): #5301: add image/vnd.microsoft.icon (.ico) MIME type
On 8/21/2011 8:10 PM, Scott Dial wrote: On 8/21/2011 3:12 PM, Terry Reedy wrote: 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. Please. It is an operational decision. I personally would be ok with doing away with bugfix-only releases and just releasing a new version with all patches every 6 months. It certainly would make issue management easier. But most people don't want such rapid change, even to the point of resisting fixes to design errors of 20 years ago. On the other hand, most people want their personal fix/feature included right away, in the next release. But if we do not include everything every release, we make decisions as what to include or not. 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 In http://bugs.python.org/msg124332 from that issue, David Murray refers to "the policy stated in mimetypes". I could not find a policy explicitly stated in the doc, not in a quick review of the code. But I believe what he meant is "Include the most commonly used subset of registered extensions. Add more as requested with every x.y version." If it is really not in the doc, I wish it, or an agreed-on revision, were added. "Add more as requested with every x.y.x release." is the alternative that Sandro seems to have followed. 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. If we intended to include all registered mimetypes and this happened to be missing, that would be a bug. But there are scads of mimetypes, especially vender-specific vnd types, that we do not include. Many predate 2003 and are probably obsolete, and hence well not included. There might be others that are used generally. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
