[ python-Bugs-1223976 ] error locale.getlocale() with LANGUAGE=eu_ES
Bugs item #1223976, was opened at 2005-06-20 08: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=1223976&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: Zunbeltz Izaola (zunbeltz) Assigned to: Nobody/Anonymous (nobody) Summary: error locale.getlocale() with LANGUAGE=eu_ES Initial Comment: I had sumited this bug (id 1177674) and it has been closed becouse my bad explanation. My locale is set to LANGUAGE=eu_ES This is what i get in the interpreter Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getlocale() (None, None) >>> locale.setlocale(locale.LC_ALL, '') 'eu_ES' >>> >>> locale.getlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 365, in getlocale return _parse_localename(localename) File "/usr/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: eu_ES >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224047 ] Len too large with national characters
Bugs item #1224047, was opened at 2005-06-20 12:52 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=1224047&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: Henrik Winther Jensen (henrikwj) Assigned to: Nobody/Anonymous (nobody) Summary: Len too large with national characters Initial Comment: It looks as if len returns the lenght of an UTF8 string even if the string only contains ascii characters and default encoding is ascii. This means that if you insert f. ex. one danish ø in a string. len will return a value of 2. i.e. a='ø' print len(a) gives: 2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224047 ] Len too large with national characters
Bugs item #1224047, was opened at 2005-06-20 11:52 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&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: Henrik Winther Jensen (henrikwj) Assigned to: Nobody/Anonymous (nobody) Summary: Len too large with national characters Initial Comment: It looks as if len returns the lenght of an UTF8 string even if the string only contains ascii characters and default encoding is ascii. This means that if you insert f. ex. one danish ø in a string. len will return a value of 2. i.e. a='ø' print len(a) gives: 2 -- >Comment By: Michael Hudson (mwh) Date: 2005-06-20 13:12 Message: Logged In: YES user_id=6656 How are you getting your danish character into the string? If it's by typing it into a console, is your console in utf-8 mode? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224047 ] Len too large with national characters
Bugs item #1224047, was opened at 2005-06-20 12:52 Message generated for change (Comment added) made by henrikwj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&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: Henrik Winther Jensen (henrikwj) Assigned to: Nobody/Anonymous (nobody) Summary: Len too large with national characters Initial Comment: It looks as if len returns the lenght of an UTF8 string even if the string only contains ascii characters and default encoding is ascii. This means that if you insert f. ex. one danish ø in a string. len will return a value of 2. i.e. a='ø' print len(a) gives: 2 -- >Comment By: Henrik Winther Jensen (henrikwj) Date: 2005-06-20 15:06 Message: Logged In: YES user_id=1299770 Actually the problem persists whether i am reading from a file or inputting from a keyboard. I am using python from the command line in linux shell. I dont know what console that is. But it is able to show the danish characters on the screen as well as reading them from the keyboard. -- Comment By: Michael Hudson (mwh) Date: 2005-06-20 14:12 Message: Logged In: YES user_id=6656 How are you getting your danish character into the string? If it's by typing it into a console, is your console in utf-8 mode? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224047 ] Len too large with national characters
Bugs item #1224047, was opened at 2005-06-20 11:52
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Henrik Winther Jensen (henrikwj)
>Assigned to: Michael Hudson (mwh)
Summary: Len too large with national characters
Initial Comment:
It looks as if len returns the lenght of an UTF8 string
even if the string
only contains ascii characters and default encoding is
ascii. This
means that if you insert f. ex. one danish ø in a
string. len will return a
value of 2. i.e.
a='ø'
print len(a)
gives:
2
--
>Comment By: Michael Hudson (mwh)
Date: 2005-06-20 14:12
Message:
Logged In: YES
user_id=6656
Well, what encoding is the file in?
I suspect that it's in utf-8, so when you open the file and
call read() you get utf-8 data and thus your danish
character is represented as two bytes.
You might want to do
import codecs
fileobj = codecs.open('filename.txt', encoding='utf-8')
and then fileobj.read() will return a unicode string of the
length you're expecting.
At any rate, I see no evidence of a Python bug here, so closing.
--
Comment By: Henrik Winther Jensen (henrikwj)
Date: 2005-06-20 14:06
Message:
Logged In: YES
user_id=1299770
Actually the problem persists whether i am reading from a
file or inputting from a keyboard. I am using python from the
command line in linux shell. I dont know what console that is.
But it is able to show the danish characters on the screen as
well as reading them from the keyboard.
--
Comment By: Michael Hudson (mwh)
Date: 2005-06-20 13:12
Message:
Logged In: YES
user_id=6656
How are you getting your danish character into the string? If it's by typing
it into a console, is your console in utf-8 mode?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1106262 ] semaphore errors from Python 2.3.x on AIX 5.2
Bugs item #1106262, was opened at 2005-01-20 20:55 Message generated for change (Comment added) made by lim_1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106262&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: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: semaphore errors from Python 2.3.x on AIX 5.2 Initial Comment: Newer versions of the AIX 5.2 libc implement POSIX semaphores and thus define _POSIX_SEMAPHORES in . However, when building Python 2.3.x (and I'm sure any other version with sem_init()), a few semaphore errors are encountered: building 'pcre' extension ./Modules/ld_so_aix gcc -bI:Modules/python.exp -L/opt/TWWfsw/python232/lib/support -Wl,-brtl -Wl,-blibpath:/opt/TWWfsw/python232/lib/support:/usr/lib build/temp.aix-5.2-2.3/pcremodule.o build/temp.aix-5.2-2.3/pypcre.o -L/opt/TWWfsw/python232/lib -o build/lib.aix-5.2-2.3/pcre.so sem_trywait: Permission denied sem_wait: Permission denied sem_post: Permission denied I ran the Python process under truss and saw that the sem_init() from Python/thread_pthread.h worked successfully. fork() was then called and a sem_trywait() operation (probably from PyThread_acquire_lock()) was called. From the sem_init() man page (http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/libs/basetrf2/sem_init.htm): If the pshared parameter has a nonzero value, the semaphore is shared between processes. In this case, any process that can access the sem parameter can use it for performing sem_wait, sem_trywait, sem_post, and sem_destroy operations. Only the sem parameter itself may be used for performing synchronization. If the pshared parameter is zero, the semaphore is shared between threads of the process. Any thread in this process can use the sem parameter for performing sem_wait, sem_trywait, sem_post, and sem_destroy operations. The use of the semaphore by threads other than those created in the same process returns an error. Setting the 2nd value of sem_init to 1 (was 0) solved the problem. However, I don't know if this is wise for security. Another solution is to set HAVE_BROKEN_POSIX_SEMAPHORES for "AIX/5" like for "SunOS/5.8". -- Comment By: Leanid (lim_1) Date: 2005-06-20 13:12 Message: Logged In: YES user_id=701470 I can confirm this problem. I am using scons to build my project on AIX. I could not run parallel builds (-j4) on AIX. Randomly, but very often xlC invocation would stuck and I have 4 xlCcode hanging and taking all CPUs. After adding HAVE_BROKEN_POSIX_SEMAPHORES for AIX and rebuilding Python parallel builds on AIX are fine. Trying first fix with changing 0 to 1 in sem_init also resolved this problem, but I started to get some other unexplained error from scons, so had to deactivate semaphores all together. Albert, thanks for this report, it helped a lot. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106262&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224047 ] Len too large with national characters
Bugs item #1224047, was opened at 2005-06-20 12:52
Message generated for change (Comment added) made by henrikwj
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&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: Closed
Resolution: Invalid
Priority: 5
Submitted By: Henrik Winther Jensen (henrikwj)
Assigned to: Michael Hudson (mwh)
Summary: Len too large with national characters
Initial Comment:
It looks as if len returns the lenght of an UTF8 string
even if the string
only contains ascii characters and default encoding is
ascii. This
means that if you insert f. ex. one danish ø in a
string. len will return a
value of 2. i.e.
a='ø'
print len(a)
gives:
2
--
>Comment By: Henrik Winther Jensen (henrikwj)
Date: 2005-06-20 15:41
Message:
Logged In: YES
user_id=1299770
Yes, you are right, the problem is that the console-thingy
converts my iso8859 characters to utf-8. Thanks for the
explanation.
--
Comment By: Michael Hudson (mwh)
Date: 2005-06-20 15:12
Message:
Logged In: YES
user_id=6656
Well, what encoding is the file in?
I suspect that it's in utf-8, so when you open the file and
call read() you get utf-8 data and thus your danish
character is represented as two bytes.
You might want to do
import codecs
fileobj = codecs.open('filename.txt', encoding='utf-8')
and then fileobj.read() will return a unicode string of the
length you're expecting.
At any rate, I see no evidence of a Python bug here, so closing.
--
Comment By: Henrik Winther Jensen (henrikwj)
Date: 2005-06-20 15:06
Message:
Logged In: YES
user_id=1299770
Actually the problem persists whether i am reading from a
file or inputting from a keyboard. I am using python from the
command line in linux shell. I dont know what console that is.
But it is able to show the danish characters on the screen as
well as reading them from the keyboard.
--
Comment By: Michael Hudson (mwh)
Date: 2005-06-20 14:12
Message:
Logged In: YES
user_id=6656
How are you getting your danish character into the string? If it's by typing
it into a console, is your console in utf-8 mode?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153016 ] Setting socket timeout crashes SSL
Bugs item #1153016, was opened at 2005-02-27 20:41
Message generated for change (Comment added) made by maltehelmert
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&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: pristine777 (pristine777)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting socket timeout crashes SSL
Initial Comment:
This bug was fixed in Python 2.3 but has resurfaced in
Python 2.4
The original bug report can be found at:
https://sourceforge.net/tracker/?
func=detail&atid=105470&aid=673797&group_id=5470
The method urlopen both in urllib and in urllib2 crashes
if socket.setdefaulttimeout has been called. Below is a
cut and paste when using the function in urllib.
>>> import socket
>>> socket.setdefaulttimeout(30.0)
>>> import urllib
>>> urllib.urlopen('https://members.tufts-
health.com/memindex.html')
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\urllib.py", line 77, in urlopen
return opener.open(url)
File "C:\Python24\lib\urllib.py", line 180, in open
return getattr(self, name)(url)
File "C:\Python24\lib\urllib.py", line 374, in open_https
h.endheaders()
File "C:\Python24\lib\httplib.py", line 794, in
endheaders
self._send_output()
File "C:\Python24\lib\httplib.py", line 675, in
_send_output
self.send(msg)
File "C:\Python24\lib\httplib.py", line 642, in send
self.connect()
File "C:\Python24\lib\httplib.py", line 1069, in connect
ssl = socket.ssl(sock, self.key_file, self.cert_file)
File "C:\Python24\lib\socket.py", line 74, in ssl
return _realssl(sock, keyfile, certfile)
IOError: [Errno socket error] (2, 'The operation did not
complete (read)')
Thanks a ton!
--
Comment By: Malte Helmert (maltehelmert)
Date: 2005-06-20 17:12
Message:
Logged In: YES
user_id=1131890
Same problem here with Python 2.4 (#1, Jan 13 2005,
20:34:41) on SuSE Linux 9.2 (i586) and imaplib. Here is a
minimal piece of code that fails (substitute a valid IMAP
server accepting SSL connections):
=== start code snippet ===
import imaplib, socket
socket.setdefaulttimeout(10.0)
imaplib.IMAP4_SSL("imap.whatever.invalid")
=== end code snippet ===
This fails with the following traceback:
=== start traceback ===
Traceback (most recent call last):
File "./imap_bug.py", line 3, in ?
imaplib.IMAP4_SSL("imap.whatever.invalid")
File "/usr/local/lib/python2.4/imaplib.py", line 1101, in
__init__
IMAP4.__init__(self, host, port)
File "/usr/local/lib/python2.4/imaplib.py", line 181, in
__init__
self.welcome = self._get_response()
File "/usr/local/lib/python2.4/imaplib.py", line 876, in
_get_response
resp = self._get_line()
File "/usr/local/lib/python2.4/imaplib.py", line 969, in
_get_line
line = self.readline()
File "/usr/local/lib/python2.4/imaplib.py", line 1135, in
readline
char = self.sslobj.read(1)
socket.sslerror: The read operation timed out
=== end traceback ===
Remove the socket.setdefaulttimeout call and it works properly.
The problem is not due to a slow network connection or
overloaded server -- the script fails for all kinds of
timeouts (1, 10, 100 seconds), but without a timeout the
response is near-instantaneous.
--
Comment By: Tarek Ziadé (tarek-ziade)
Date: 2005-05-19 15:53
Message:
Logged In: YES
user_id=1163510
having same issue here, using imaplib thru ssl :/
>>> import socket
>>> socket.setdefaulttimeout(10)
>>> i = imaplib.IMAP4_SSL('mail..com')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/imaplib.py", line 1101, in __init__
IMAP4.__init__(self, host, port)
File "/usr/lib/python2.4/imaplib.py", line 181, in __init__
self.welcome = self._get_response()
File "/usr/lib/python2.4/imaplib.py", line 876, in
_get_response
resp = self._get_line()
File "/usr/lib/python2.4/imaplib.py", line 969, in _get_line
line = self.readline()
File "/usr/lib/python2.4/imaplib.py", line 1136, in readline
char = self.sslobj.read(1)
socket.sslerror: The read operation timed out
so i can't get timeouts with ssl in imap :/
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163563 ] Sub threads execute in restricted mode
Bugs item #1163563, was opened at 2005-03-15 08:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: anothermax (yetanothermax) >Assigned to: Michael Hudson (mwh) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done -- >Comment By: Michael Hudson (mwh) Date: 2005-06-20 17:54 Message: Logged In: YES user_id=6656 Fixed, in Misc/NEWS revision 1.1301 Modules/threadmodule.c revision 2.64 Python/pystate.c revision 2.42 (I made a tiny tweak in addition to the latest patch attached to this report). yetanothermax: Thanks for the report, and the testing of patches! -- Comment By: anothermax (yetanothermax) Date: 2005-06-17 15:37 Message: Logged In: YES user_id=1218811 The maybe-even-better-1010677-fix also seems to work -- Comment By: Michael Hudson (mwh) Date: 2005-06-17 13:10 Message: Logged In: YES user_id=6656 That's good to hear. Tim: could you glance over the attached? If you can't be assed to read all the various reports, I've attempted to summarise the problem(s) here: http://mail.python.org/pipermail/python-dev/2005-June/054258.html If you don't have time, please at least say so... yetanothermax: thanks for the confirmation. Could you also try this cleaner version of the patch? Wrt your patch, it took me too long to work out that it was simply unapplying the earlier changes -- and you don't need to supply a patch for that, even creaky old CVS makes *that* easy :) -- Comment By: anothermax (yetanothermax) Date: 2005-06-17 11:35 Message: Logged In: YES user_id=1218811 Good news - I've made a couple of tests and the patch seems to fix the problem. With regards to the earlier patch: - apologies for not running the test suite - I feel suitably chastised :) & I'll be sure to run it in the future. - I did note that it would probably re-raise #1010677 (see 2005-04-20 13:51 comment) but guessed it was more important to contribute the patch so that someone who has better thread implementation knowledge could look into it... -- Comment By: Michael Hudson (mwh) Date: 2005-06-16 13:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a hack, and I certainly wouldn't condone applying it to the trunk as is but I would be interested in hearing if it fixes your problems. (after applying your patch the test suite failed to complete, btw -- please try this yourself next time :)
[ python-Bugs-1221424 ] buffer() object broken.
Bugs item #1221424, was opened at 2005-06-15 11:17
Message generated for change (Comment added) made by rjs_org
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&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 Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Schumacher (rjs_org)
Assigned to: Neil Schemenauer (nascheme)
Summary: buffer() object broken.
Initial Comment:
Same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470:
Still broken in 2.4.1...!
C:\projects\temp\fftw>python
ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on
Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import Numeric
>>> i = Numeric.zeros(8)
>>> repr(buffer(i))
''
>>> repr(buffer(""))
''
(Numeric v23.8)
--
>Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-20 11:11
Message:
Logged In: YES
user_id=287034
No, since we have now used the PyObject_AsReadBuffer().
We use ctypes to transfer data returned from an C-API A/D
driver directly to Numeric arrays via address.
--
Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-18 10:26
Message:
Logged In: YES
user_id=35752
Calling PyObject_AsReadBuffer() is the proper way to get the
address. It should work with older versions of Python as
well. The buffer() object was changed in 2.4 to no longer
keep a pointer to buffer memory, only the underlying
PyObject. It would be possible to make the repr look the
same as pre-2.4 Python. Do you still care?
--
Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-17 12:04
Message:
Logged In: YES
user_id=287034
In 2.3, the actual adress of the first element of an array
could be parsed for doing a memmove(), and now, not, which
breaks some older code. If this is a "more Pythonic"
feature, then OK; the previous resolution said "Fixed in
bufferobject.c 2.25." without remark. I assumed that it had
been restored to the previous.
I now have:
ptr = tpcnv[a.typecode()]()
pythonapi.PyObject_AsReadBuffer(py_object(a),
byref(ptr),
byref(c_int()))
ptr.refed_array = a
instead of:
split(repr(buffer(a)))[5][:-1]
to get/use an address with ctypes...
--
Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-17 10:52
Message:
Logged In: YES
user_id=35752
The repr of a buffer() object has indeed changed. I don't
see how that's a bug though.
--
Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-17 10:31
Message:
Logged In: YES
user_id=287034
repr(buffer("")) used to return:
now returns:
>>> repr(buffer(""))
''
same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470
--
Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-16 11:49
Message:
Logged In: YES
user_id=35752
Please explain exactly what you think is broken about the
buffer object.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224347 ] int/long unification and hex()
Bugs item #1224347, was opened at 2005-06-20 12: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=1224347&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 Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: int/long unification and hex()
Initial Comment:
There seems to be a bit of an inconsistancy with
int/long unification while using hex(). Specifically;
>>> hex(int(987259835))
'0x3ad863bb'
>>> hex(long(987259835))
'0x3AD863BBL'
I understand that longs will have the trailing 'L'
until Py3k, but I believe the capitalization should be
consistant. If consistancy is desired, I believe that
lowercase should be the standard, being that
string.encode('hex') also produces lowercase.
If the cases are supposed to be different, or making
the change would produce known backwards
incompatibility for some set of modules, feel free to
close this bug report.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224347&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1215928 ] Large tarfiles cause overflow
Bugs item #1215928, was opened at 2005-06-06 21:19 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&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: Tom Emerson (tree) Assigned to: Martin v. Löwis (loewis) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int -- Comment By: Viktor Ferenczi (complex) Date: 2005-06-21 01:44 Message: Logged In: YES user_id=142612 The bug has been reproduced with a 90Mbytes bz2 file containing more than 4Gbytes of fairly similar documents. I've diagnosed the same problem with large offsets. Thanks for the patch. Platform: WinXP Intel P4, Python 2.4.1 -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-19 00:05 Message: Logged In: YES user_id=80475 Martin, please look at this when you get a chance. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 23:26 Message: Logged In: YES user_id=1188172 I looked into this a bit further, and noticed the following: The modules bz2, cStringIO and mmap all use plain integers to represent file offsets given to or returned by seek(), tell() and truncate(). They should be corrected to use a 64-bit type when having large file support. fileobject.c defines an own type for that, Py_off_t, which should be shared among the other modules. Conditional compile is needed since different macros/functions must be used. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-13 03:32 Message: Logged In: YES user_id=80475 Is there a way to write a test for this? Can it be done without a conditional compile? Is the problem one that occurs in other code outside of bz? -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 13:45 Message: Logged In: YES user_id=1188172 Attaching corrected patch. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 22:31 Message: Logged In: YES user_id=1188172 Attaching a patch which mimics the behaviour of normal file objects. This should resolve the issue on platforms with large file support. -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-06-07 15:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1221424 ] buffer() object broken.
Bugs item #1221424, was opened at 2005-06-15 18:17
Message generated for change (Settings changed) made by nascheme
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&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 Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Ray Schumacher (rjs_org)
Assigned to: Neil Schemenauer (nascheme)
Summary: buffer() object broken.
Initial Comment:
Same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470:
Still broken in 2.4.1...!
C:\projects\temp\fftw>python
ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on
Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import Numeric
>>> i = Numeric.zeros(8)
>>> repr(buffer(i))
''
>>> repr(buffer(""))
''
(Numeric v23.8)
--
Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-20 18:11
Message:
Logged In: YES
user_id=287034
No, since we have now used the PyObject_AsReadBuffer().
We use ctypes to transfer data returned from an C-API A/D
driver directly to Numeric arrays via address.
--
Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-18 17:26
Message:
Logged In: YES
user_id=35752
Calling PyObject_AsReadBuffer() is the proper way to get the
address. It should work with older versions of Python as
well. The buffer() object was changed in 2.4 to no longer
keep a pointer to buffer memory, only the underlying
PyObject. It would be possible to make the repr look the
same as pre-2.4 Python. Do you still care?
--
Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-17 19:04
Message:
Logged In: YES
user_id=287034
In 2.3, the actual adress of the first element of an array
could be parsed for doing a memmove(), and now, not, which
breaks some older code. If this is a "more Pythonic"
feature, then OK; the previous resolution said "Fixed in
bufferobject.c 2.25." without remark. I assumed that it had
been restored to the previous.
I now have:
ptr = tpcnv[a.typecode()]()
pythonapi.PyObject_AsReadBuffer(py_object(a),
byref(ptr),
byref(c_int()))
ptr.refed_array = a
instead of:
split(repr(buffer(a)))[5][:-1]
to get/use an address with ctypes...
--
Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-17 17:52
Message:
Logged In: YES
user_id=35752
The repr of a buffer() object has indeed changed. I don't
see how that's a bug though.
--
Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-17 17:31
Message:
Logged In: YES
user_id=287034
repr(buffer("")) used to return:
now returns:
>>> repr(buffer(""))
''
same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470
--
Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-16 18:49
Message:
Logged In: YES
user_id=35752
Please explain exactly what you think is broken about the
buffer object.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224621 ] tokenize module does not detect inconsistent dedents
Bugs item #1224621, was opened at 2005-06-21 06:10 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=1224621&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: Danny Yoo (dyoo) Assigned to: Nobody/Anonymous (nobody) Summary: tokenize module does not detect inconsistent dedents Initial Comment: The attached code snippet 'testcase.py' should produce an IndentationError, but does not. The code in tokenize.py is too trusting, and needs to add a check against bad indentation as it yields DEDENT tokens. I'm including a diff to tokenize.py that should at least raise an exception on bad indentation like this. Just in case, I'm including testcase.py here too: -- import tokenize from StringIO import StringIO sampleBadText = """ def foo(): bar baz """ print list(tokenize.generate_tokens( StringIO(sampleBadText).readline)) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
