➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2003-07-20 11:59 by mpeti, last changed 2022-04-10 16:10 by admin. This issue is now closed.
| Messages (6) | |||
|---|---|---|---|
| msg17131 - (view) | Author: Michael Peternell (mpeti) | Date: 2003-07-20 11:59 | |
>>> c = "Österreich" UnicodeError: ASCII encoding error: ordinal not in range(128) the parser must not consider the German language an error. the same for French: >>> c = "Kate Ryan - Désenchantée" UnicodeError: ASCII encoding error: ordinal not in range(128) I think this behavior was INTENDED, or why did the error message say "ordinal not in range(128)"? This is not an error. It is intended that bytes have 8 bits and not 7. I hope you don't reject this bug. Michael |
|||
| msg17132 - (view) | Author: Marc-Andre Lemburg (lemburg) *  |
Date: 2003-07-20 14:15 | |
Logged In: YES user_id=38388 Are you sure about this ? /home/lemburg> python2.2 Python 2.2.3 (#1, Jul 1 2003, 10:54:49) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> c = "Österreich" >>> Same for Python 2.3. Perhaps you have change something in your site.py file ?! |
|||
| msg17133 - (view) | Author: Michael Peternell (mpeti) | Date: 2003-07-20 16:03 | |
Logged In: YES user_id=809932 Hi lemburg, no, I haven't. It seems the problem only exists on Windows. I am using Windows XP. Look at this URL: http://www.python.org/doc/current/tut/node5.html (Chapter 3.1.3): "...The default encoding is normally set to ASCII, which passes through characters in the range 0 to 127 and rejects any other characters with an error. ..." But they are writing strings in the form u"blabla". Maybe Windows converts everything to Unicode automatically? But thank you anyways. The problem only exists with 2.2.3 and only with Idle. The Dos-Version (python.exe) works proplerly. I've downloaded python 2.3c1 now and everything works fine. But it isn't perfect anyways... >>> x = "Österreich" >>> x '\xd6sterreich' >>> print x Österreich >>> "ññ" '\xf1\xf1' '\xd6' doesn't look very nice, but as long as you can print it, it's not a big problem. and it can parse char(0xf1) (or Alt-164, which equals 0xa4) too. Michael |
|||
| msg17134 - (view) | Author: Marc-Andre Lemburg (lemburg) * |
Date: 2003-07-20 16:17 | |
Logged In: YES user_id=38388 Ah, so it's an IDLE problem, not a Python one. AFAIK, IDLE behaves much better wir to Unicode in the version that comes with Python 2.3. |
|||
| msg17135 - (view) | Author: Martin v. Löwis (loewis) * |
Date: 2003-07-20 21:12 | |
Logged In: YES user_id=21627 As Marc-Andre explains, this bug is fixed in Python 2.3. |
|||
| msg17136 - (view) | Author: Terry J. Reedy (terry.reedy) * |
Date: 2003-07-20 21:59 | |
Logged In: YES user_id=593130 The difference between '>>> x' printing repr(x) and '>>> print x' printing str(x) is, I believe, intended. Unless you can identify an actual bug in 2.2.3 or 2.3rc1 or later + new Idle, please close this. The open bug list is already too long (at 370+). In the future, including version, system, and IDE (if applicable) in the original report would usually be helpful. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-10 16:10:03 | admin | set | github: 38881 |
| 2003-07-20 11:59:31 | mpeti | create | |