diff options
author | Fedora Python maintainers <python-devel@lists.fedoraproject.org> | 2020-07-15 13:14:59 (GMT) |
---|---|---|
committer | Petr Viktorin <pviktori@redhat.com> | 2020-09-29 13:31:09 (GMT) |
commit | 3aa4074d50e5e1b0f75165bad71335417442b3a4 (patch) | |
tree | fc471239014481e163b88f54ee396f7c3ff1bd7c /Python/random.c | |
parent | 559c4163ea3c9d7160ca3518c517f1d5326d6552 (diff) | |
download | cpython-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/random.c')
0 files changed, 0 insertions, 0 deletions