[ python-Bugs-1288615 ] Python code.interact() and UTF-8 locale
Bugs item #1288615, was opened at 2005-09-12 13:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1288615&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: STINNER Victor (haypo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python code.interact() and UTF-8 locale
Initial Comment:
Hi,
I found a bug in Python interactive command line
(program python alone: looks to be code.interact()
function in code.py). With UTF-8 locale, the command <<
u"é" >> returns << u'\xc3\xa9' >> and not << u'\xE9'
>>. Remember: the french e with acute is Unicode 233
(0xE9), encoded \xC3 \xA9 in UTF-8.
Another example of the bug:
#-*- coding: UTF-8 -*-
code = "u\%s\" % "\xc3\xa9"
compiled = compile(code,'',"single")
exec compiled
Result :
u'\xc3\xa9'
Excepted result :
u'\xe9'
After long hours of debuging (read Python
documentation, debug Python with gdb, read Python C
source code, ...) I found the origin of the bug:
function parsestr() in Python/compile.c. This function
translate a string to a unicode string (or a classic
string). The problem is when the encoding declaration
doesn't exist: the string isn't converted.
Solution to the first code:
#-*- coding: ascii -*-
code = """#-*- coding: UTF-8 -*-
u\%s\""" % "\xc3\xa9"
compiled = compile(code,'',"single")
exec compiled
Proposition: u"..." and unicode("...") should use
sys.stdin.encoding by default. They will work as
unicode("...", sys.stdin.encoding). Or easier, the
compiler should use sys.stdin.encoding and not ascii as
default encoding.
Sorry if someone already reported this bug. And, is it
a bug or a feature ? ;-)
Bye, Haypo
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1288615&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1288615 ] Python code.interact() and UTF-8 locale
Bugs item #1288615, was opened at 2005-09-12 13:40
Message generated for change (Comment added) made by haypo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1288615&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: STINNER Victor (haypo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python code.interact() and UTF-8 locale
Initial Comment:
Hi,
I found a bug in Python interactive command line
(program python alone: looks to be code.interact()
function in code.py). With UTF-8 locale, the command <<
u"é" >> returns << u'\xc3\xa9' >> and not << u'\xE9'
>>. Remember: the french e with acute is Unicode 233
(0xE9), encoded \xC3 \xA9 in UTF-8.
Another example of the bug:
#-*- coding: UTF-8 -*-
code = "u\%s\" % "\xc3\xa9"
compiled = compile(code,'',"single")
exec compiled
Result :
u'\xc3\xa9'
Excepted result :
u'\xe9'
After long hours of debuging (read Python
documentation, debug Python with gdb, read Python C
source code, ...) I found the origin of the bug:
function parsestr() in Python/compile.c. This function
translate a string to a unicode string (or a classic
string). The problem is when the encoding declaration
doesn't exist: the string isn't converted.
Solution to the first code:
#-*- coding: ascii -*-
code = """#-*- coding: UTF-8 -*-
u\%s\""" % "\xc3\xa9"
compiled = compile(code,'',"single")
exec compiled
Proposition: u"..." and unicode("...") should use
sys.stdin.encoding by default. They will work as
unicode("...", sys.stdin.encoding). Or easier, the
compiler should use sys.stdin.encoding and not ascii as
default encoding.
Sorry if someone already reported this bug. And, is it
a bug or a feature ? ;-)
Bye, Haypo
--
>Comment By: STINNER Victor (haypo)
Date: 2005-09-12 14:46
Message:
Logged In: YES
user_id=365388
Ok ok, after long discution with RexFi on IRC, I understood
that Python can't *guess* string encoding ... I agree with
that, system locale or source encoding are not a good choice.
But ... Python console have a bug. It uses raw_input(). So I
wrote a patch to just add the right unicode cast. But Python
console don't looks to be code.interact().
I attach the patch to this comment.
Haypo
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1288615&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1289118 ] timedelta multiply and divide by floating point
Bugs item #1289118, was opened at 2005-09-12 14:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1289136 ] distutils extension library path bug on cygwin
Bugs item #1289136, was opened at 2005-09-12 15:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Whitley (jwhitley)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils extension library path bug on cygwin
Initial Comment:
A while back I reported a problem on the Cygwin mailing
list where all python extension packages would fail
"python setup.py install" at the link step due to a
mangled lib dir (-L) option. distutils was producing a
link line with "-L.", instead of the desired
"-L/usr/lib/python2.4/config". I've finally rooted out
the cause of this problem.
The relevant code is the if-block starting at line 188 of:
/usr/lib/python2.4/distutils/command/build_ext.py
I've reproduced that block here for clarity of
discussion (indentation truncated for redability)
if sys.platform[:6] == 'cygwin' or sys.platform[:6]
== 'atheos':
if string.find(sys.executable, sys.exec_prefix)
!= -1:
# building third party extensions
self.library_dirs.append(os.path.join(sys.prefix, "lib",
"python" +
get_python_version(),
"config"))
else:
# building python standard extensions
self.library_dirs.append('.')
The test "string.find(...) != -1" attempts to test
whether "/usr" appears in the full executable name.
This incorrectly fails in the case that /bin is in the
user's path before /usr/bin. (i.e.
string.find("/bin/python","/usr") == -1) Note that a
vagary of Cygwin is that /usr/bin is a Cygwin mount to
/bin.
The user-side workaround is to ensure that /usr/bin
appears in your path before /bin. It looks like a new
and improved Cygwin special case test is needed to fix
this problem; I'm not sure offhand what the best case
would be. Perhaps an outright test as follows would work:
sys.executable.startswith(sys.exec_prefix) or
sys.executable.startswith(os.sep+"bin")
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1289210 ] PyDoc crashes at os.py line 133
Bugs item #1289210, was opened at 2005-09-12 20:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: PyDoc crashes at os.py line 133 Initial Comment: Details of the attempted runs are given below: C:\Python24\Lib>python pydoc.py sys Help on built-in module sys: NAME sys FILE (built-in) MODULE DOCS http://www.python.org/doc/current/lib/module-sys.html etc. etc. The above works OK but the following - advertised in the PyDoc.py comment - fails. --- C:\Python24\Lib>pydoc sys 'import site' failed; use -v for traceback Traceback (most recent call last): File "C:\Python24\Lib\pydoc.py", line 54, in ? import sys, imp, os, re, types, inspect, __builtin__ File "C:\Python24\Lib\os.py", line 133 from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, ^ SyntaxError: invalid syntax Lines 132 to 134 of os.py: sys.modules['os.path'] = path from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, devnull) The above "from X import" usage appears legitimate. Colin W. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1289210 ] PyDoc crashes at os.py line 133
Bugs item #1289210, was opened at 2005-09-12 19:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: PyDoc crashes at os.py line 133 Initial Comment: Details of the attempted runs are given below: C:\Python24\Lib>python pydoc.py sys Help on built-in module sys: NAME sys FILE (built-in) MODULE DOCS http://www.python.org/doc/current/lib/module-sys.html etc. etc. The above works OK but the following - advertised in the PyDoc.py comment - fails. --- C:\Python24\Lib>pydoc sys 'import site' failed; use -v for traceback Traceback (most recent call last): File "C:\Python24\Lib\pydoc.py", line 54, in ? import sys, imp, os, re, types, inspect, __builtin__ File "C:\Python24\Lib\os.py", line 133 from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, ^ SyntaxError: invalid syntax Lines 132 to 134 of os.py: sys.modules['os.path'] = path from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, devnull) The above "from X import" usage appears legitimate. Colin W. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-12 23:10 Message: Logged In: YES user_id=80475 This is probably invalid. It looks like you may have multiple python versions running on your system and that the pydoc batch file is invoking an earlier version of the interpreter that doesn't understand multiline imports). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1289118 ] timedelta multiply and divide by floating point
Bugs item #1289118, was opened at 2005-09-12 16:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) >Assigned to: Tim Peters (tim_one) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-12 23:11 Message: Logged In: YES user_id=80475 Tim, do you prefer the current behavior? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
