[ python-Bugs-1379393 ] StreamReader.readline doesn't advance on decode errors
Bugs item #1379393, was opened at 2005-12-13 02:35 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=1379393&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: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: StreamReader.readline doesn't advance on decode errors Initial Comment: In previous versions of python, when there was a unicode decode error, StreamReader.readline() would advance to the next line. In the current version(2.4.2 and trunk), it doesn't. Testing under Linux AMD64 (Ubuntu 5.10) Attaching an example script. In python2.3 it prints: hi~ hi error: 'utf8' codec can't decode byte 0x80 in position 2: unexpected code byte error: 'utf8' codec can't decode byte 0x81 in position 2: unexpected code byte all done In python2.4 and trunk it prints: hi~ hi error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte [repeats forever] Maybe this isn't actually supposed to work (the docs don't mention what should happen with strict error checking..), but it would be nice, given the alternatives: 1. use errors='replace' and then search the result for the replacement character. (ick) 2. define a custom error handler similar to ignore or replace, that also sets some flag. (slightly less ick, but more work.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379416 ] email.Header encode() unicode P2.3xP2.4
Bugs item #1379416, was opened at 2005-12-13 12:09
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=1379416&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jan Novak (xnovakj)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.Header encode() unicode P2.3xP2.4
Initial Comment:
Python: 2.4
Module: email.Header
Method: encode()
In some cases returns unicode (example on line 5)
1>> from email.Header import Header
2>> Header(unicode('abcá','iso-8859-2'),'utf-8').encode()
'=?utf-8?b?YWJjw6E=?='
3>> Header('abc','utf-8').encode()
'=?utf-8?q?abc?='
4>> Header(u'abc','utf-8').encode()
'abc' ???
5>> Header('abc','iso-8859-2').encode()
u'=?iso-8859-2?q?abc?=' (P2.4)
6>> Header('abc','iso-8859-2').encode()
'=?iso-8859-2?q?abc?=' (P2.3)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379416&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1379573 ] python executable optionally should search script on PATH
Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379804 ] HP-UX thread stack size needs to be increased
Bugs item #1379804, was opened at 2005-12-13 20:22
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=1379804&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: Documentation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Blade (blade_doyle)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP-UX thread stack size needs to be increased
Initial Comment:
On HP-UX the default thread stack size is
"insufficient" and probably needs to be increased if
threads are performing any heavy tasks. Obviously, the
ideal size depends on you application but I find that
THREAD_STACK_SIZE=0x5 works well for me.
Using the default thread stack size my multi-threading
tests were failing with a corrupt stack sometimes and
this stack trace other times:
#0 0x79db8c0c in _isspace+0x2d8 () from
/usr/lib/libnss_dns.1
#1 0x7aff62c4 in nss_search+0x28c () from /usr/lib/libc.2
#2 0x7af4d320 in __gethostbyname_r+0x140 () from
/usr/lib/libc.2
#3 0x7af4d4bc in gethostbyname+0x94 () from
/usr/lib/libc.2
#4 here, I am calling: gethostbyname("localhost")
[cut]
#23 0x7a8c49ac in OpSession::begin+0x1c0 ()
from /space/bdoyle/hprisc/lib/oopython.sl
#24 0x7aa42660 in PyCFunction_Call+0xc8 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
[cut]
#38 0x7aabbda0 in PyEval_CallObjectWithKeywords+0x1c4 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
#39 0x7ab17e8c in t_bootstrap+0xa0 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
#40 0x7ab6400c in __pthread_body+0x44 () from
/usr/lib/libpthread.1
#41 0x7ab6e29c in __pthread_start+0x14 () from
/usr/lib/libpthread.1
I tested both Python 2.3.4 and 2.4.2 and increased
stack size solves the probem on both.
I suggest that a note be added to the Python README
under the HP-UX section. The note should suggest that
the "BASECFLAGS" environment variable be set to include
"-DTHREAD_STACK_SIZE=0x5" prior to running
configure. I dont know that 0x5 is really the
ideal stack size.
Blade.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379984 ] HP-UX: Can't shl_load() a library containing Thread Local
Bugs item #1379984, was opened at 2005-12-14 00:20 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=1379984&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: Threads Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Blade (blade_doyle) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: Can't shl_load() a library containing Thread Local Initial Comment: HP-UX runtime loader does not support dynamic load of shared libraries that contain (TLS) thread local storage. As a result, when attempting to import modules that contain TLS the following error is reported: "/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage" This problem was discussed previously on the python.org mail list: http://mail.python.org/pipermail/python-list/2003-May/164024.html There is another option: Use LD_PRELOAD environment variable to cuase the runtime loader to 'pre-load' the pthreads library (and dependancies of the pthread library). See the dld.sl(5) man page for more info on LD_PRELOAD. But, I think a 5th option is ideal. If libpthread.sl (and the dependancies of libpthread) are linked into the python executable at build time then all of these problems are avoided. I suggest that the HP-UX (includes hp-ux on ia64) build process be modified so that libpthead (and depends) are linked in. Or, at least, make a note of this problem/solution in the HP-UX section of the README file distributed with python source. Here is the process I use to work around the TLS problem: HP-UX: bash$ BASECFLAGS="-DTHREAD_STACK_SIZE=0x5"; export BASECFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs='-lpthread -lstd_v2 -lCsup_v2 -lcl' bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install HP-UX on ia64: bash$ CC=cc; export CC bash$ CXX=aCC; export CXX bash$ BASECFLAGS="+DD64 -DTHREAD_STACK_SIZE=0x5"; export BASECFLAGS bash$ LDFLAGS="+DD64"; export LDFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs="-lpthread -lCsup -lstd_v2 -lunwind" bash$ unset CC bash$ unset CXX bash$ unset BASECFLAGS bash$ unset LDFLAGS bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken
Bugs item #1379994, was opened at 2005-12-13 19:47
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=1379994&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: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Mc Mahon (markmcmahon)
Assigned to: M.-A. Lemburg (lemburg)
Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken
Initial Comment:
In Python 2.4.2 and Python 2.4.1 (Windows XP)
>>> "\t\t".encode("string_escape")
'\t\\t'
>>> "\t\t".encode("unicode_escape")
'\t\t'
>>> "\t\t".encode("raw_unicode_escape")
'\t\t'
>>> u"\t\t".encode("unicode_escape")
'\t\t'
>>> u"\t\t".encode("raw_unicode_escape")
'\t\t'
I would have expected all to produce the same result.
Also round-tripping with the encoding doesn't seem to work:
>>> "\t\t".encode('string_escape').decode('string_escape')
'\t\t'
>>>
u"\t\t".encode('unicode_escape').decode('unicode_escape')
u'\t\t'
Thanks
Mark
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken
Bugs item #1379994, was opened at 2005-12-14 09:47
Message generated for change (Comment added) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&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: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Mc Mahon (markmcmahon)
Assigned to: M.-A. Lemburg (lemburg)
Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken
Initial Comment:
In Python 2.4.2 and Python 2.4.1 (Windows XP)
>>> "\t\t".encode("string_escape")
'\t\\t'
>>> "\t\t".encode("unicode_escape")
'\t\t'
>>> "\t\t".encode("raw_unicode_escape")
'\t\t'
>>> u"\t\t".encode("unicode_escape")
'\t\t'
>>> u"\t\t".encode("raw_unicode_escape")
'\t\t'
I would have expected all to produce the same result.
Also round-tripping with the encoding doesn't seem to work:
>>> "\t\t".encode('string_escape').decode('string_escape')
'\t\t'
>>>
u"\t\t".encode('unicode_escape').decode('unicode_escape')
u'\t\t'
Thanks
Mark
--
>Comment By: Hye-Shik Chang (perky)
Date: 2005-12-14 10:41
Message:
Logged In: YES
user_id=55188
Attached a patch. It looks like a simple typo. :)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1369116 ] freeze idle-python2.3 on my debia n sarge
Bugs item #1369116, was opened at 2005-11-29 07:37 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&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: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Santonja (gsantonja) Assigned to: Nobody/Anonymous (nobody) Summary: freeze idle-python2.3 on my debia n sarge Initial Comment: When I press space bar continusly idle-python task have a random freeze 8/10 times before the caracter 300. I must kill the task and restart This arrive frequently during my development. Architecture : idle python 2.3 Debian sarge without modification XFCE 4.0 Nvidia driver hp nx9105 I have try to made again the bug on other architecture but i don't have success on windows XP and debion in virtual pc. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-12-14 01:06 Message: Logged In: YES user_id=149084 What happens when you start IDLE with no subprocess (use the -n switch)? You say it happens frequently in development. I assume that you mean that in normal use after typing for some time IDLE will freeze. Correct? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378305 ] Import value 1e400 from pyc fails
Bugs item #1378305, was opened at 2005-12-11 13:09 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Guenter Jantzen (gjantzen) Assigned to: Nobody/Anonymous (nobody) Summary: Import value 1e400 from pyc fails Initial Comment: --- #file: bug.py #sys.version_info (2, 4, 2, 'final', 0) #Platform is Windows XP import sys, bug infinity = 1e400 if __name__ == "__main__": import bug print "Infinity is", bug.infinity -- This code behaves correct using bug.py - when bug.pyc is not up to date / not exists: Infinity is 1.#INF and behaves wrong using bug.pyc - when bug.pyc is up to date: Infinity is 1.0 -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-13 22:10 Message: Logged In: YES user_id=341410 This is a known bug with Python and floating point infinity literals. You can use: infinity = 1e155 * 1e155 I believe this is fixed in the latest Python 2.5 SVN. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed
Bugs item #1370380, was opened at 2005-11-30 13:18 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-13 22:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard asyncore.loop/poll() from the control flow. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
