Mailman 3 August 2000 - Python-Dev

Bug #112265: Tkinter seems to treat everything as Latin 1
by Fredrik Lundh Aug. 26, 2000

Aug. 26, 2000

summary: Tkinter passes 8-bit strings to Tk without any preprocessing. Tk itself expects UTF-8, but passes bogus UTF-8 data right through... or in other words, Tkinter treats any 8-bit string that doesn't contain valid UTF-8 as an ISO Latin 1 string... ::: maybe Tkinter should raise a UnicodeError instead (just like string comparisions etc). example: w = Label(text="<cp1250 string>") UnicodeError: ASCII decoding error: ordinal not in range(128) this will break existing code,… [View More] but I think that's better than confusing the hell out of anyone working on a non-Latin-1 platform... +0 from myself -- there's no way we can get a +1 solution (source encoding) into 2.0 without delaying the release... ::: for some more background, see the bug report below, and my followup. </F> --- Summary: Impossible to get Win32 default font encoding in widgets Details: I did not managed to obtain correct font encoding in widgets on Win32 (NT Workstation, Polish version, default encoding cp1250). All cp1250 Polish characters were displayed incorrectly. I think, all characters that do not belong to Latin-1 will be displayed incorrectly. Regarding Python1.6b1, I checked the Tcl/Tk installation (8.3.2). The pure Tcl/Tk programs DO display characters in cp1250 correctly. As far as I know, the Tcl interpreter woks with UTF-8 encoded strings. Does Python1.6b1 really know about it? --- Follow-Ups: Date: 2000-Aug-26 08:04 By: effbot Comment: this is really a "how do I", rather than a bug report ;-) ::: In 1.6 and beyond, Python's default 8-bit encoding is plain ASCII. this encoding is only used when you're using 8-bit strings in "unicode contexts" -- for example, if you compare an 8-bit string to a unicode string, or pass it to a subsystem designed to use unicode strings. If you pass an 8-bit string containing characters outside the ASCII range to a function expecting a unicode string, the result is undefined (it's usually results in an exception, but some subsystems may have other ideas). Finally, Tkinter now supports Unicode. In fact, it assumes that all strings passed to it are Unicode. When using 8-bit strings, it's only safe to use plain ASCII. Tkinter currently doesn't raise exceptions for 8-bit strings with non-ASCII characters, but it probably should. Otherwise, Tk will attempt to parse the string as an UTF-8 string, and if that fails, it assumes ISO-8859-1. ::: Anyway, to write portable code using characters outside the ASCII character set, you should use unicode strings. in your case, you can use: s = unicode("<a cp1250 string>", "cp1250") to get the platform's default encoding, you can do: import locale language, encoding = locale.getdefaultlocale() where encoding should be "cp1250" on your box. ::: The reason this work under Tcl/Tk is that Tcl assumes that your source code uses the platform's default encoding, and converts things to Unicode (not necessarily UTF-8) for you under the hood. Python 2.1 will hopefully support *explicit* source encodings, but 1.6/2.0 doesn't. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112265&group_id=5470 [View Less]

2 2

cPickle
by Thomas Wouters Aug. 26, 2000

Aug. 26, 2000

I just noticed that test_cpickle makes Python crash (with a segmentation fault) when there is no copy_reg. The funny bit is this: centurion:~ > ./python Lib/test/regrtest.py test_cpickle test_cpickle test test_cpickle skipped -- No module named copy_reg 1 test skipped: test_cpickle centurion:~ > ./python Lib/test/regrtest.py test_cookie test_cpickle test_cookie test test_cookie skipped -- No module named copy_reg test_cpickle Segmentation fault (core dumped) I suspect there is a bug … [View More]

1 0

test_gettext fails on Windows
by Tim Peters Aug. 26, 2000

Aug. 26, 2000

Don't know whether this is unique to Win98. test test_gettext failed -- Writing: 'mullusk', expected: 'bacon\012T' Here's -v output: test_gettext installing gettext calling bindtextdomain with localedir . . None gettext gettext mullusk .py 1.1 Throatwobble nudge nudge mullusk .py 1.1 Throatwobble nudge nudge mullusk .py 1.1 Throatwobble nudge nudge mullusk .py 1.1 Throatwobble nudge nudge This module provides internationalization and localization support for your Python programs by … [View More]

1 1

Python 1.6 bug fix strategy
by Jeremy Hylton Aug. 26, 2000

Aug. 26, 2000

We have gotten several bug reports recently based on 1.6b1. What plans, if any, are there to fix these bugs before the 1.6 final release? We clearly need to fix them for 2.0b1, but I don't know about 1.6 final. Among the bugs are 111403 and 11860, which cause core dumps. The former is an obvious bug and has a fairly clear fix. Jeremy PS Will 1.6 final be released before 2.0b1?

3 2

Fixing test_poll.py for me just broke it for you
by Tim Peters Aug. 26, 2000

Aug. 26, 2000

Here's the checkin comment. See test/README for an expanded explanation if the following isn't clear: Another new test using "from test.test_support import ...", causing subtle breakage on Windows (the test is skipped here, but the TestSkipped exception wasn't recognized as such, because of duplicate copies of test_support got loaded; so the test looks like a failure under Windows instead of a skip). Repaired the import, but THIS TEST *WILL* FAIL ON OTHER SYSTEMS NOW! Again due to … [View More]

2 1

Looking for a DL_xxPORT macro export
by Tim Peters Aug. 26, 2000

Aug. 26, 2000

Somebody recently added DL_IMPORT macros to two module init functions that already used their names in DL_EXPORT macros (pyexpat.c and parsermodule.c). On Windows, that yields the result I (naively?) expected: compiler warnings about inconsistent linkage declarations. This is your basic Undocumented X-Platform Macro Hell, and I suppose the Windows build should be #define'ing USE_DL_EXPORT for these subprojects anyway (?), but if I don't hear a good reason for *why* both macros are used on the … [View More]

3 3

Compilation failure, current CVS
by Charles G Waldman Aug. 25, 2000

Aug. 25, 2000

Just a heads-up - I suspect this is a trivial problem, but I don't have time to investigate right now ("real life"). Linux buffalo.fnal.gov 2.2.16 #31 SMP gcc version 2.95.2 19991024 (release) After cvs update and make distclean, I get this error: make[1]: Entering directory `/usr/local/src/Python-CVS/python/dist/src/Python' gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c -o errors.o errors.c:368: arguments given to macro `PyErr_BadInternalCall' make[1]: *** [errors.o] Error 1

1 1

Strange compiler crash in debug builds.
by Mark Hammond Aug. 25, 2000

Aug. 25, 2000

Something strange is happening in my Windows Debug builds (fresh CVS tree) If you remove "urllib.pyc", and execute 'python_d -c "import urllib"', Python dies after printing the message: FATAL: node type 305, required 311 It also happens for a number of other files (compileall.py will show you :-) Further analysis shows this deep in the compiler, and triggered by this macro in node.h: --- /* Assert that the type of a node is what we expect */ #ifndef Py_DEBUG #define REQ(n, type) { /*pass*/ … [View More]

5 7

(214)
by Just van Rossum Aug. 25, 2000

Aug. 25, 2000

(Just to make sure you guys know; there's currently a thread in c.l.py about the new 2.0 features. Not a *single* person stood up to defend PEP 214: noone seems to like it.) Just

6 9

warning in initpyexpat
by Jeremy Hylton Aug. 25, 2000

Aug. 25, 2000

gcc -Wall is complaining about possible use of errors_module without initialization in the initpyexpat function. Here's the offending code: sys_modules = PySys_GetObject("modules"); { PyObject *errmod_name = PyString_FromString("pyexpat.errors"); if (errmod_name != NULL) { errors_module = PyDict_GetItem(d, errmod_name); if (errors_module == NULL) { errors_module = PyModule_New("pyexpat.errors"); if (errors_module … [View More]

2 1