[Bug 243541] default encoding is ascii, should be UTF-8, produces exceptions for i18n applications
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=243541
Dave Malcolm <dmalcolm(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|9 |12
--- Comment #3 from Dave Malcolm <dmalcolm(a)redhat.com> 2009-12-14 15:50:37 EDT ---
John: I spent some time reviewing this today; here are my notes:
Looking over the source history in upstream's Subversion:
- the site.py hook to set the default encoding from the locale was added on
June 7th 2000 in rev 15634:
'Added support to set the default encoding of strings
at startup time to the values defined by the C locale...'
- http://svn.python.org/view?view=rev&revision=15634
- the code was disabled by default 5 weeks later on July 15th 2000 in rev
16374 by effbot (Fredrik Lundh):
-- changed default encoding to "ascii". you can still change
the default via site.py...:
http://svn.python.org/view?view=rev&revision=16374
- and the code was optimized two months later on Sept 18th 2000 in rev 17513,
to only set it if it's changed:
http://svn.python.org/view?view=rev&revision=17513
Looking over upstream mailing list archives for this period:
[Python-Dev] changing the locale.py interface?: Fredrik Lundh
<effbot(a)telia.com>
http://mail.python.org/pipermail/python-dev/2000-July/005827.html
followed by:
http://mail.python.org/pipermail/python-dev/2000-July/005954.html "ascii
default encoding":
http://mail.python.org/pipermail/python-dev/2000-July/006724.html
(unfortunately side-tracked into a debate of "deprecated" vs "depreciated"); I
may have missed some of the discussion though.
The actual affect of calling: sys.setdefaultencoding:
It is defined in Python/sysmodule.c, it calls
PyUnicode_SetDefaultEncoding(encoding) on the string "encoding"
PyUnicode_SetDefaultEncoding is defined in Objects/unicodeobject.c; it has this
code:
/* Make sure the encoding is valid. As side effect, this also
loads the encoding into the codec registry cache. */
v = _PyCodec_Lookup(encoding);
then copies the encoding into the buffer: "unicode_default_encoding"; this
buffer supplies the return value for PyUnicode_GetDefaultEncoding(), which is
used in many places inside the unicode implementation, plus in
bytearrayobject.c: bytearray_decode()
and in stringobject.c: PyString_AsDecodedObject()
PyString_AsEncodedObject()
so it would seem that there's at least some risk in changing this setting.
To add to the confusion, Py_InitializeEx sets up the encoding of each of
stdout, stderr, stdin to the default locale encoding (UTF-8), _provided_ they
are connected to a tty:
#0 PyFile_SetEncodingAndErrors (f=0xb7fc5020, enc=0x80edc28 "UTF-8",
errors=0x0) at Objects/fileobject.c:458
#1 0x04fbdd49 in Py_InitializeEx (install_sigs=<value optimized out>) at
Python/pythonrun.c:322
#2 0x04fbe29e in Py_Initialize () at Python/pythonrun.c:359
#3 0x04fc9886 in Py_Main (argc=<value optimized out>, argv=<value optimized
out>) at Modules/main.c:512
#4 0x080485c7 in main (argc=<value optimized out>, argv=<value optimized out>)
at Modules/python.c:23
which means that a simple case (printing lower case greek alpha, beta, gamma)
works when run directly:
[david@brick ~]$ python -c 'print u"\u03b1\u03b2\u03b3"'
αβγ
>>> sys.getdefaultencoding()
'ascii'
>>> sys.stdout.encoding
'UTF-8'
>>> sys.stderr.encoding
'UTF-8'
...but fails if you pipe it to a file or redirected into "less":
python -c 'print u"\u03b1\u03b2\u03b3"' > foo.txt
[david@brick ~]$ python -c 'print u"\u03b1\u03b2\u03b3"' | less
Traceback (most recent call last):
File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2:
ordinal not in range(128)
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 4 months
[Bug 301861] File playback seeking using the slider does not work for FLAC files
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=301861
Rex Dieter <rdieter(a)math.unl.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kevin(a)tigcc.ticalc.org,
| |ltinkl(a)redhat.com,
| |lvillani(a)binaryhelix.net,
| |smparrish(a)gmail.com,
| |than(a)redhat.com
Component|xine-lib |phonon
AssignedTo|gauret(a)free.fr |rdieter(a)math.unl.edu
--- Comment #20 from Rex Dieter <rdieter(a)math.unl.edu> 2009-12-13 13:53:27 EDT ---
Tested this on f12, and seems to be more phonon related now.
xine-ui was (mostly) ok, both kaffeine (kde4/phonon based) and amarok behaved
similarly, where seeking *kinda* worked, but just not all that reliably.
Fwiw, tested both xine/gstreamer backends, and a bit surprisingly, -xine worked
a little bit better here.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 4 months
[Bug 301861] File playback seeking using the slider does not work for FLAC files
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=301861
--- Comment #19 from Edgar Hoch <edgar.hoch(a)ims.uni-stuttgart.de> 2009-12-12 23:32:32 EDT ---
Note: My machine used for this test runs fedora 10.
I tried kaffeine and seeking works with a .flac file.
I tried the same in amarok and I can't seek - when moving the song position
slider it still jumps back to an area around the old position - and sometimes a
small part of the audio is skipped.
To comment #16:
I removed xine-lib-extras-freeworld and restarted amarok and kaffeine.
I see no difference with and without this package.
Versions:
xine-lib-1.1.16.3-2.fc10.x86_64
xine-ui-0.99.5-16.fc10.x86_64
xine-lib-extras-1.1.16.3-2.fc10.x86_64
xine-lib-extras-freeworld-1.1.16.3-1.fc10.x86_64
xine-plugin-1.0.1-4.fc10.x86_64
xine-lib-pulseaudio-1.1.16.3-2.fc10.x86_64
amarok-libs-2.2.1-2.fc10.x86_64
amarok-utils-2.2.1-2.fc10.x86_64
amarok-2.2.1-2.fc10.x86_64
kaffeine-0.8.7-3.fc10.x86_64
kaffeine-libs-0.8.7-3.fc10.x86_64
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 4 months