Changes by Georg Brandl ge...@python.org:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4742
___
___
Python-bugs-list
Changes by Tarek Ziadé ziade.ta...@gmail.com:
--
assignee: - tarek
nosy: +tarek
priority: - normal
type: - crash
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4742
___
Tarek Ziadé ziade.ta...@gmail.com added the comment:
Here's a status:
The problem is located in the codec that decodes the data (called by the
compile builtin).
It throws an error :
*** UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
position 853: character maps to undefined
John Machin sjmac...@users.sourceforge.net added the comment:
TWO POINTS:
(1) I am not very concerned about chars like \x9d which are not valid in
the declared encoding; I am more concerned with chars like \x93 and \x94
which *ARE* valid in the declared encoding. Please ensure that these
cases
Marc-Andre Lemburg m...@egenix.com added the comment:
On 2008-12-30 13:20, John Machin wrote:
byte-compiling C:\python26\Lib\site-packages\x9d.py to x9d.pyc
SyntaxError: ('unknown encoding: cp1252',
('C:\\python26\\Lib\\site-packages\\x9d.py', 0, 0, None))
byte-compiling
Tarek Ziadé ziade.ta...@gmail.com added the comment:
yup, here's the test I have written to demonstrate the problem. In any
case, compile doesn't behave right way in the first place.
--
keywords: +patch
Added file: http://bugs.python.org/file12493/encoding.issue.patch
Changes by Tarek Ziadé ziade.ta...@gmail.com:
Removed file: http://bugs.python.org/file12493/encoding.issue.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4742
___
Changes by Tarek Ziadé ziade.ta...@gmail.com:
Added file: http://bugs.python.org/file12494/encoding.issue.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4742
___
John Machin sjmac...@users.sourceforge.net added the comment:
(1) what am I supposed to infer from Yup?? That all of that \x9d stuff
was a mistake?
(2)
+def tearDown(self):
+pyc_file = os.path.join(os.path.dirname(__file__), 'cp1252.pyc')
+if os.path.exists(pyc_file):
+
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
This is a duplicate of issue4626.
Here, the content is correctly decoded with cp1252, then passed to
compile(); but compile() works on the internal utf-8 representation, and
tries to decode it again with cp1252!
Yes, the error message
Changes by Tarek Ziadé ziade.ta...@gmail.com:
--
resolution: - duplicate
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4742
___
___
New submission from John Machin sjmac...@users.sourceforge.net:
File foo3.py is [cut down (orig 87Kb)] output of 2to3 conversion tool
and (coincidentally) is still valid 2.x syntax. There are no syntax
errors reported by any of the following:
\python26\python -c import foo3
John Machin sjmac...@users.sourceforge.net added the comment:
A clue:
print(ascii(b'\xa0\x93\x94\xb7'.decode('cp1252')))
'\xa0\u201c\u201d\xb7'
Could be that it only happens where there's a cp1252 character that's
not in latin1; see files x93.py and x94.py (have problem) and xa0b7.py
(doesn't
Changes by John Machin sjmac...@users.sourceforge.net:
Removed file: http://bugs.python.org/file12445/py3encbug.zip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4742
___
14 matches
Mail list logo
