summaryrefslogtreecommitdiffstats
path: root/Python/dynload_os2.c
diff options
context:
space:
mode:
authorFedora Python maintainers <python-devel@lists.fedoraproject.org>2020-07-15 13:14:59 (GMT)
committerPetr Viktorin <pviktori@redhat.com>2020-09-29 13:31:09 (GMT)
commit3aa4074d50e5e1b0f75165bad71335417442b3a4 (patch)
treefc471239014481e163b88f54ee396f7c3ff1bd7c /Python/dynload_os2.c
parent559c4163ea3c9d7160ca3518c517f1d5326d6552 (diff)
downloadcpython-3aa4074d50e5e1b0f75165bad71335417442b3a4.zip
cpython-3aa4074d50e5e1b0f75165bad71335417442b3a4.tar.gz
cpython-3aa4074d50e5e1b0f75165bad71335417442b3a4.tar.bz2
python-2.5.1-sqlite-encoding.patch
00007 # This patch was listed in the changelog as: * Fri Sep 14 2007 Jeremy Katz <katzj@redhat.com> - 2.5.1-11 - fix encoding of sqlite .py files to work around weird encoding problem in Turkish (#283331) A traceback attached to rhbz 244016 shows the problem most clearly: a traceback on attempting to import the sqlite module, with: "SyntaxError: encoding problem: with BOM (__init__.py, line 1)" This seems to come from Parser/tokenizer.c:check_coding_spec Our patch changes two source files within sqlite3, removing the "coding: ISO-8859-1" specs and character E4 = U+00E4 = LATIN SMALL LETTER A WITH DIAERESIS from in ghaering's surname. It may be that the conversion of "ISO-8859-1" to "iso-8859-1" is thwarted by the implementation of "tolower" in the Turkish locale; see: https://bugzilla.redhat.com/show_bug.cgi?id=191096#c9 TODO: Not yet sent upstream, and appears to me (dmalcolm 2010-01-29) that it may be papering over a symptom
Diffstat (limited to 'Python/dynload_os2.c')
0 files changed, 0 insertions, 0 deletions