Mark Lawrence added the comment:
@Christoph please raise a new issue regarding the problem you describe in
msg219788.
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
Mark Lawrence added the comment:
@Christoph sorry #21652 has already been raised to address the problem of mixed
str and unicode objects.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
Changes by Brian Curtin br...@python.org:
--
nosy: -brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
___
___
Python-bugs-list
Christoph Zwerschke added the comment:
After this patch, some of the values in mimetypes.types_map now appear as
unicode instead of str in Python 2.7.7 under Windows. For compatibility and
consistency reasons, I think this should be fixed so that all values are
returned as str again under
Roundup Robot added the comment:
New changeset 95b88273683c by Tim Golden in branch '3.3':
Issue #15207: Fix mimetypes to read from correct area in Windows registry
(Original patch by Dave Chambers)
http://hg.python.org/cpython/rev/95b88273683c
New changeset 12bf7fc1ba76 by Tim Golden in
Roundup Robot added the comment:
New changeset e8cead08c556 by Tim Golden in branch '2.7':
Issue #15207: Fix mimetypes to read from correct area in Windows registry
(Original patch by Dave Chambers)
http://hg.python.org/cpython/rev/e8cead08c556
--
Tim Golden added the comment:
*cough* Somehow that didn't actually get pushed. Rebased against 2.7, 3.3 3.4
and pushed.
--
assignee: - tim.golden
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
versions: -Python 3.2
Tim Golden added the comment:
Thanks for the review, Ben. Updated patches attached.
1 3) default_encoding -- Your two points appear to contradict each
other slightly. What's in the updated patches is: 3.x has no encoding
(because everything's unicode end-to-end); 2.7 attempts to apply the
Ben Hoyt added the comment:
All looks great. I like what you've done with default_encoding now. Thanks, Tim
(and Dave for the original report).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
Ben Hoyt added the comment:
Thanks, Tim! Works for me! A couple of code review comments:
1) On 2.7, guess_type(s)[0] is a byte string as usual if the type doesn't exist
in the registry, but it's a unicode string if it came from the registry. Seems
like it should be a byte string in all cases
Tim Golden added the comment:
I attach a patch against 3.3; this is substantially Dave Chambers' original
patch with a trivial test added and a doc change. This means that HKCR is
scanned to determine extensions and these will override anything in the
mimetypes db. The doc change highlights
Tim Golden added the comment:
Attached is a qd script to produce the list of extension - mimetype maps for
a version of the mimetypes module.
--
Added file: http://bugs.python.org/file29900/mt.py
___
Python tracker rep...@bugs.python.org
Tim Golden added the comment:
Three outputs produced by mt.py: tip as-is; tip without registry; tip
with new approach to registry. The results for 2.7 are near-enough
identical. Likewise the results for an elevated prompt.
--
Added file: http://bugs.python.org/file29901/mt-tip.txt
Added
Tim Golden added the comment:
There seems to be a consensus that the current behaviour is undesirable,
indeed broken for any meaningful use.
The critical argument against the current Registry approach is that it
returns unexpected (or outright incorrect) mimetypes for very standard
extensions.
Marc-Andre Lemburg added the comment:
I think it's important to stick to established standards for
MIME types and to make sure that Python returns the same values
on all platforms using the default settings.
Apache comes with a mime.types file which includes both the
official IANA types and
Dave Chambers added the comment:
Enough with the bikeshedding... it's been 10 months... fix the bug.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
___
Brian Curtin added the comment:
Just an FYI, but if it takes 10 more months to get it right, we'll do that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
___
Ben Hoyt added the comment:
Okay, I'm looking at the diff between mt-tip-noregistry.txt and
mt-tip-newregistry.txt, and I've attached a file showing the lines that are
*different* between the two, as well as the Apache mime.types value for that
file extension.
In most cases, noregistry gives
Ben Hoyt added the comment:
Any update on this, Tim or other Windows developers?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
___
___
Brian Curtin added the comment:
I can't comment on what the change should be or how it should be done as I
don't do anything with mimetypes, but nothing about how the patch was written
jumps out at me for being incorrect (except I would not include ishimoto's name
changes).
If there's a
R. David Murray added the comment:
I'm personally OK with the option of removing the registry support (or making
it optional-by-default), but I'm not going to make that call, we need a windows
dev opinion.
Maintaining the list of windows exceptions shouldn't be much worse than
maintaining
Dave Chambers added the comment:
(I'm a windows dev type)
I would say that there are 2 issues with relying on the registry:
1) Default values (ie. set by Windows upon OS install) are broken and MS never
fixes them.
2) The values can be changed at any time, by any app. Thus the values are
R. David Murray added the comment:
I would say Brian Curtin, Tim Golden, and/or Martin von Löwis, as
they are the currently active committers with significant Windows expertise.
Other committers may have opinions as well. If you don't get an answer here in
a reasonable amount of time, please
Terry J. Reedy added the comment:
Gabriel and Antoine: As I understand it, the claim in this issue is that the
patch in #4969 (G. wrote, A. committed) is unsatisfactory. I think it would
help if either of you commented.
--
nosy: +gagenellina, pitrou
Antoine Pitrou added the comment:
I'll leave it to a Windows expert.
--
versions: -Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
___
Changes by Antoine Pitrou pit...@free.fr:
--
stage: commit review - patch review
versions: +Python 2.7, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
___
Tim Golden added the comment:
Sorry; late to the party. I'll try to take a look at the patches.
Basically I'm sympathetic to the problem (which seems quite
straightforwardly buggish) but I want to take a look around the issue first.
TJG
--
___
Ben Hoyt added the comment:
Either way -- this needs to be reverted or fixed. It's a nasty gotcha for folks
writing Python web services at the moment. I'm still for reverting, per my
reasons above.
Dave Chambers, I'm not for faster but broken but for faster and fixed --
from what I've shown
Dave Chambers added the comment:
removing read_windows_registry()
If you're suggesting hardcoding *ALL* the mimetypes for *ALL* OSes, I think
that's probably the best overall solution.
No variability, as fast as can be.
The downside is that there would occasionally be an unrecognized type,
Ben Hoyt added the comment:
Actually, I was suggesting using the hardcoded types for Windows only (i.e.,
only removing read_windows_registry). Several bugs have been opened on problems
with the Windows registry mimetypes, but as far as I know this isn't an issue
on Linux -- in other words, if
Dave Chambers added the comment:
Disappointing that faster but broken is preferable to slower but fixed
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
___
R. David Murray added the comment:
I will note that on unix the user is also free to update the machine's mime
types registry (that's more than half the point of the mimetypes module).
Usually this is only done by installed software...as I believe is the case on
Windows as well.
That said,
R. David Murray added the comment:
That said, the fact that windows is just *wrong* about some mimetypes is
definitely an issue. We could call it a platform bug, but that would be a
disservice to the user community.
--
___
Python tracker
Dave Chambers added the comment:
Seems to me that some hybrid would be a good solution: Hardcode the known types
(which solves the windows is just wrong case) then as a default look in the
registry for those that aren't hardcoded.
Therefore the hit of additional time would only be for
R. David Murray added the comment:
To be consistent with the overall philosophy of the mimetypes module, it should
be instead a list of windows fixes which are applied if the broken mimetype
is found in the windows registry.
If you want to avoid the overhead, pass an empty list to init. A
Ben Hoyt added the comment:
Ah, thanks for making this an issue of its own! As I commented over at
Issue10551, it's a serious problem, and makes mimetypes.guess_type() unusable
out of the box on Windows.
Yes, the fix in Issue4969 uses MIME\Database\Content Type, which is a mime
type - file
R. David Murray added the comment:
Unfortunately I don't feel qualified to review the patch itself since I'm not a
windows user and don't currently even have a windows box to test on. Hopefully
one of the windows devs will take a look; the patch looks to be fairly
straightforward to evaluate
Yap Sok Ann added the comment:
On Python 2.7, I need to add this to the original diff by Dave, in the same
try-except block:
mimetype = mimetype.encode(default_encoding) # omit in 3.x!
--
nosy: +sayap
___
Python tracker rep...@bugs.python.org
Atsuo Ishimoto ishim...@gembook.org added the comment:
This patch looks good to me.
I generated a patch for current trunk, with some cosmetic changes.
--
nosy: +ishimoto
Added file: http://bugs.python.org/file26507/issue15207.patch
___
Python
New submission from Dave Chambers dlchamb...@aol.com:
The current mimetypes.read_windows_registry() enums the values under
HKCR\MIME\Database\Content Type
However, this is the key for mimetype to extension lookups, NOT for extension
to mimetype lookups.
As a result, when 1 MIME types are
R. David Murray rdmur...@bitdance.com added the comment:
Thanks for working on this. Could you please post the fix as a patch file? If
you don't have mercurial, you can generate the diff on windows using the python
diff module (scripts/diff.py -u yourfile origfile). Actually, I'm not sure
Dave Chambers dlchamb...@aol.com added the comment:
My first diff file... I hope I did it right :)
--
keywords: +patch
Added file: http://bugs.python.org/file26181/mimetypes.py.diff
___
Python tracker rep...@bugs.python.org
Dave Chambers dlchamb...@aol.com added the comment:
I added a diff file to the bug.
Dunno if that's the same as a patch file, or how to create a patchfile if it's
not.
Do you know if image/x-png and image/png are included in the registry on all
windows versions?
I think your question is
R. David Murray rdmur...@bitdance.com added the comment:
Well, I had no involvement in the windows registry reading stuff, and it is
relatively new. And, as issue 10551 indicates, a bit controversial. (issue
15199 is a different bug, in python's own internal table).
Can you run that diff
Changes by Dave Chambers dlchamb...@aol.com:
Added file: http://bugs.python.org/file26185/mimetypes.py.diff.u
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15207
___
45 matches
Mail list logo
