Jean-Paul Calderone added the comment:
Please see http://bugs.python.org/issue21652 for a regression introduced by
this change.
--
nosy: +exarkun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
Roundup Robot added the comment:
New changeset 18cfc2a42772 by Tim Golden in branch '2.7':
Issue #9291 Do not attempt to re-encode mimetype data read from registry in
ANSI mode. Initial patches by Dmitry Jemerov Vladimir Iofik
http://hg.python.org/cpython/rev/18cfc2a42772
--
nosy:
Roundup Robot added the comment:
New changeset 0c8a7299c7e3 by Tim Golden in branch '2.7':
Issue #9291 Add ACKS NEWS
http://hg.python.org/cpython/rev/0c8a7299c7e3
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
stoyanov added the comment:
Alternative temporary solution
def enum_types(mimedb):
try:
ctype = ctype.encode(default_encoding) # omit in 3.x!
except UnicodeEncodeError:
pass
except Exception: #--
pass#--
else:
yield ctype
--
nosy: +quick.es
Changes by Tim Golden m...@timgolden.me.uk:
Removed file: http://bugs.python.org/file34925/issue9291.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
Tim Golden added the comment:
Another version of the patch: this one, in addition to removing the unnecessary
encodes, also does the check for extensions before attempting to open the
registry key, and narrows down the try-catch block to just the attempt to read
the Content Type value.
This
Tim Golden added the comment:
The attached patch issue9291.7.patch (which is essentially an amalgam of
9291.patch 9291a.patch with some tweaks of my own) does appear to solve the
issue. My Windows setup is UK, so if any of the people still watching this
issue could test against a non-English
Michał Pasternak added the comment:
I just hit this bug on 2.7.6, running on polish WinXP (I need to build some
packages there, I hope I'll avoid a nasty py2exe bug). Any reasons this is not
fixed yet? Do you need any assistance?
--
nosy: +Michał.Pasternak
Martin v. Löwis added the comment:
Michał: Can you please report the exact registry key and value that is causing
the problem? It's difficult to test a patch if one is not able to reproduce the
problem.
Of the patches suggested: does any of them fix the problem for you? If so,
which one?
I
Daniel Szoska added the comment:
Martin: I had the same problem after upgrading to 2.7.6.
System here: German XP 32 Bit
I used the solution from Alexandr with sitecustomize.py (with cp1252) and it
works fine for me.
--
___
Python tracker
Michał Pasternak added the comment:
Another REG file, encoded with CP1250, I believe.
--
Added file: http://bugs.python.org/file34188/issue9291-key.reg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
Michał Pasternak added the comment:
Martin: the problematic key is [HKEY_CLASSES_ROOT\BDATuner.Składniki]. I am
pasting its name, because I suppose, that as bugs.python.org is utf-8, special
characters will be pasted properly.
Included you will find a .REG file, which is Windows Registry
Michał Pasternak added the comment:
As for the fix, sitecustomize.py works for me, too, but I somehow believe, that
adding sitecustomize.py for new Python installations would propably do more
harm than good. I'll check those 2 patches and I'll let you know.
--
Michał Pasternak added the comment:
9291.patch works for me too, but I am unsure about its idea. Silently ignoring
non-ASCII registry entries - does it sound like a good idea? Maybe. Is it
pythonic? I doubt so.
I don't exactly understand what 9291a.patch is doing. For me it does look like
a
Changes by Daniel Szoska d.szo...@steinreichwald.de:
--
nosy: +Daniel.Szoska
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
___
Jason R. Coombs added the comment:
The bug as reported against setuptools:
https://bitbucket.org/pypa/setuptools/issue/127/unicodedecodeerror-when-install-in-windows
--
nosy: +jason.coombs
___
Python tracker rep...@bugs.python.org
Alexandr Zarubkin added the comment:
An alternative solution, which worked for me, is:
add file named sitecustomize.py in Lib\site-packages folder.
The contents of the file:
import sys
sys.setdefaultencoding(cp1251)
The default encoding should be determined for every localized Windows version.
R. David Murray added the comment:
OK, that means the issue 15207 fix didn't fix it, since that's in 2.7.6.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
Tim Golden added the comment:
I'll try to look at this soonish. Thanks for bringing it back to the
surface.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
STINNER Victor added the comment:
Issue #20017 has been marked as a duplicate of this issue. Copy of the message:
Running Windows 8 (64-bit) and Python 2.7.6 (64-bit).
python -m SimpleHTTPServer
Traceback (most recent call last):
File C:\Python27\lib\runpy.py, line 162, in
Takayuki SHIMIZUKAWA added the comment:
This issue affects mercurial too.
http://bz.selenic.com/show_bug.cgi?id=3624
--
nosy: +shimizukawa
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
Suzumizaki added the comment:
There is possibility that the installation of setuptools fails with
any Windows machine because of this bug. I want change the priority of this
issue higher...
I failed the installation of setuptools with Python 2.7.6 on my machine,
Windows 8.1 Pro Japanese
adamhj added the comment:
The encoding is wrong. We should read the registry using Unicode, or at least
use the correct encoding. The correct encoding is the ANSI code page:
sys.getfilesystemencoding().
Can you please try with: default_encoding = sys.getfilesystemencoding() ?
This does
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +adamhj
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
___
Python-bugs-list
Tim Golden added the comment:
Only just been reminded of this one; it's possible that it's been superseded by
Issue15207. At the least, that issue resulted in a code change in this area of
mimetypes. I'll have a look later.
--
nosy: +tim.golden
___
Changes by Roman Evstifeev someuniquen...@gmail.com:
--
nosy: +Roman.Evstifeev
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
___
STINNER Victor added the comment:
File c:\Python27\lib\mimetypes.py, line 250, in enum_types
ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0:
ordinal not in range(128)
The encoding is wrong. We should read
Changes by Francis Devereux python@devrx.org:
--
nosy: +frankoid
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
___
Python-bugs-list
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
___
Python-bugs-list mailing list
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +aclover
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
___
Python-bugs-list
Vladimir Iofik v-io...@yandex.ru added the comment:
Here is a better patch.
--
nosy: +vj
Added file: http://bugs.python.org/file19332/9291a.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
Vladimir Iofik v-io...@yandex.ru added the comment:
UnicodeDecodeException is thrown because 'ctype' is already a string,
so it is first implicitly decoded by default encoder (which is 'ascii') and
then reencoded back. I see no reason in all these actions, so I simply removed
them. I think
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +vldmit
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
___
Python-bugs-list
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
___
Python-bugs-list
kai zhu kaizhu...@gmail.com added the comment:
python 3.1.2 mimetypes initialization also fails in redhat linux:
import http.server
Traceback (most recent call last):
File
/home/public/i386-redhat-linux-gnu/python/lib/python3.1/http/server.py, line
588, in module
class
Dmitry Jemerov intelliy...@gmail.com added the comment:
Patch (suggested fix and unittest) attached.
--
keywords: +patch
Added file: http://bugs.python.org/file18143/9291.patch
___
Python tracker rep...@bugs.python.org
Dmitry Jemerov intelliy...@gmail.com added the comment:
And by the way I've verified that the problem doesn't happen in py3k trunk.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
R. David Murray rdmur...@bitdance.com added the comment:
And just for clarity: py3k trunk does contain the _winreg code path.
--
stage: unit test needed - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
Changes by Brian Curtin cur...@acm.org:
--
nosy: +brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
___
___
Python-bugs-list mailing
Dmitry Jemerov intelliy...@gmail.com added the comment:
The problem doesn't happen on Python 3.1.2 because it doesn't have the code in
mimetypes that accesses the Windows registry. Haven't tried the 3.2 alphas yet.
--
___
Python tracker
R. David Murray rdmur...@bitdance.com added the comment:
I'm guessing this problem doesn't occur in 3.x? If so, the quick fix would be
to have the registry code catch UnicodeError instead of UnicodeEncodeError.
That may be the correct fix anyway.
The fun part of this bug is going to be
New submission from Dmitry Jemerov intelliy...@gmail.com:
On Windows, mimetypes initialization reads the list of MIME types from the
Windows registry. It assumes that all characters are Latin-1 encoded, and fails
when it's not the case, with the following exception:
Traceback (most recent
43 matches
Mail list logo
