[ python-Bugs-1732629 ] Built-in open function fail. Too many file open
Bugs item #1732629, was opened at 2007-06-07 16: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=1732629&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: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732629&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1732662 ] socket makefile objects are not independent
Bugs item #1732662, was opened at 2007-06-07 11:50
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=1732662&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
Private: No
Submitted By: Jan Ondrej (ondrejj)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket makefile objects are not independent
Initial Comment:
Running some python 2.4 code on python 2.5 does not work properly. Python
documentation for socket library says:
makefile( [mode[, bufsize]])
Return a file object associated with the socket. (File objects are
described in 3.9, ``File Objects.'') The file object references a dup()ped
version of the socket file descriptor, so the file object and socket object may
be closed or garbage-collected independently.
It is true for python 2.4, but not for python 2.5 (at least not one in Fedora
7). Closing socket and then using file descriptor does not work. Here is an
example code:
import socket
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(('salstar.sk', 25))
f=s.makefile('rw')
s.shutdown(1)
s.close()
print f.readline()
It writes "220 work.salstar.sk ESMTP Postfix" in python 2.4 but raises an
exception for python 2.5:
Traceback (most recent call last):
File "socktest.py", line 9, in
print f.readline()
File "/usr/lib/python2.5/socket.py", line 345, in readline
data = self._sock.recv(self._rbufsize)
socket.error: (9, 'Bad file descriptor')
Is it a bug of python 2.5 or a bug in documentation?
Or is it Fedora specific? Can somebody test it on other systems?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732662&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1732629 ] Built-in open function fail. Too many file open
Bugs item #1732629, was opened at 2007-06-07 08:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732629&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: Python 2.3 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 10:20 Message: Logged In: YES user_id=849994 Originator: NO This is very likely not caused by a Python bug. Please discuss your script and the error in the comp.lang.python group. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732629&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1732686 ] Built-in open function fail. Too many file open
Bugs item #1732686, was opened at 2007-06-07 18:28 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=1732686&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: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1732686 ] Built-in open function fail. Too many file open
Bugs item #1732686, was opened at 2007-06-07 10:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&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: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 13:08 Message: Logged In: YES user_id=849994 Originator: NO Please do *not* open another bug when your first one was closed! If you think closing it was not correct, reopen the first one. In this case, however, I referred you to comp.lang.python, so *please* post the issue (and your script) there. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1430435 ] urllib2 has memory leaks
Bugs item #1430435, was opened at 2006-02-13 04:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430435&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: Duplicate Priority: 5 Private: No Submitted By: halfik (halfik) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 has memory leaks Initial Comment: reg = urllib2.Request(url, data, headers) rl_handle = urllib2.urlopen(reg) urllib2 has hot memory leaks. gc: uncollectable <_fileobject memory_adres> gc: uncollectable -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 13:41 Message: Logged In: YES user_id=849994 Originator: NO Dupe of #1208304. -- Comment By: Facundo Batista (facundobatista) Date: 2007-03-31 12:36 Message: Logged In: YES user_id=752496 Originator: NO How did you produce those results? (how can I reproduce them?) In which Python version you did? Regards, -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430435&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1732686 ] Built-in open function fail. Too many file open
Bugs item #1732686, was opened at 2007-06-07 18:28 Message generated for change (Comment added) made by alexteo21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&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: Python 2.3 >Status: Open Resolution: Rejected Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex -- >Comment By: Alex (alexteo21) Date: 2007-06-07 22:22 Message: Logged In: YES user_id=1810740 Originator: YES Additional info I am running the script on solaris. If I have a similar script in tcl but there is no issue there. It only happens on python -- Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 21:08 Message: Logged In: YES user_id=849994 Originator: NO Please do *not* open another bug when your first one was closed! If you think closing it was not correct, reopen the first one. In this case, however, I referred you to comp.lang.python, so *please* post the issue (and your script) there. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1732686 ] Built-in open function fail. Too many file open
Bugs item #1732686, was opened at 2007-06-07 10:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&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: Python 2.3 >Status: Pending Resolution: Rejected Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 15:31 Message: Logged In: YES user_id=849994 Originator: NO We can't even remotely guess at the source of your exception with that info, even using our best crystal balls. But I see that you have posted on comp.lang.python, so let's see what comes out of it there. -- Comment By: Alex (alexteo21) Date: 2007-06-07 14:22 Message: Logged In: YES user_id=1810740 Originator: YES Additional info I am running the script on solaris. If I have a similar script in tcl but there is no issue there. It only happens on python -- Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 13:08 Message: Logged In: YES user_id=849994 Originator: NO Please do *not* open another bug when your first one was closed! If you think closing it was not correct, reopen the first one. In this case, however, I referred you to comp.lang.python, so *please* post the issue (and your script) there. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-799428 ] tk_focusNext() fails
Bugs item #799428, was opened at 2003-09-02 16:58
Message generated for change (Comment added) made by lither
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=799428&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: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Perry Greenfield (perrygreenfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: tk_focusNext() fails
Initial Comment:
Calls to the widget method tk_focusNext() fail with
"unsubscriptable object" error. Looking at the Tkinter.py
code for the routine shows this statement:
name = self.tk.call('tk_focusNext', self._w)
(line 433)
which used to return a string in 2.2 but now returns
a "cmdName object". When this is passed to
self._nametowidget(name), it fails when it tries to
subscript name (line 1006) since the object does
not support indexing. Perhaps str(name) or
name.string is more appropriate now? (when
that change is made, it works--well, I tested
name.string and that worked)
Perry Greenfield ([EMAIL PROTECTED])
--
Comment By: Rick Litherland (lither)
Date: 2007-06-07 12:44
Message:
Logged In: YES
user_id=1797212
Originator: NO
This problem still persists, at least in Python 2.4. As noted by Perry
Greenfield, the same problem occurs in tk_focusPrev, and some other methods
as well. Rather than track down all such calls it would be easier to add
the line
name = str(name)
at the top of the nametowidget method.
Rick Litherand.
[EMAIL PROTECTED]
--
Comment By: David Douard (douardda)
Date: 2005-11-09 09:03
Message:
Logged In: YES
user_id=692511
The problem is still not resolved for now (AFAIK).
Here is a very simple patch for Tkinter.py:
*** 432,442
--- 432,446
to 0."""
name = self.tk.call('tk_focusNext', self._w)
if not name: return None
+ try: name=name.string
+ except: pass
return self._nametowidget(name)
def tk_focusPrev(self):
"""Return previous widget in the focus order. See
tk_focusNext for details."""
name = self.tk.call('tk_focusPrev', self._w)
if not name: return None
+ try: name=name.string
+ except: pass
return self._nametowidget(name)
def after(self, ms, func=None, *args):
"""Call function once after given time.
Note: I have made this (try/except) cause I have encountered
cases where "name" was still a string (well, at least with
Python 2.3.1).
David (david.douard*gmail.com)
--
Comment By: Jeff Epler (jepler)
Date: 2003-09-07 10:23
Message:
Logged In: YES
user_id=2772
Presumably, _nametowidget() should be modified to work properly with a
"cmdName object", rather than modifying each site that gets a
widget path from a tk command.
--
Comment By: Perry Greenfield (perrygreenfield)
Date: 2003-09-03 08:29
Message:
Logged In: YES
user_id=252130
Presumably the same problem exists with tk_focusPrev.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=799428&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout
Bugs item #1729930, was opened at 2007-06-02 09:51 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [EMAIL PROTECTED] ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 -- >Comment By: David Favor (dfavor) Date: 2007-06-07 13:20 Message: Logged In: YES user_id=370230 Originator: YES The test_timeout problem appears solved in latest svn. Neal, I'm new to Python. Let me know how to approach debugging this and I'll let you know what happens. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 21:02 Message: Logged In: YES user_id=33168 Originator: NO David, I don't have access to a fedora 6 box. Could you either debug the problem or provide access to such a box? I think I have seen the curses problem somewhere else, so this may be an API issue that the python module doesn't handle it correctly. -- Comment By: David Favor (dfavor) Date: 2007-06-06 14:00 Message: Logged In: YES user_id=370230 Originator: YES Answering platform request. Fedora 6 with latest patches. -- Comment By: David Favor (dfavor) Date: 2007-06-06 10:39 Message: Logged In: YES user_id=370230 Originator: YES Latest 'svn up' shows both these tests still failing in both the 2.5.1 and 2.6 trees. -- Comment By: David Favor (dfavor) Date: 2007-06-06 10:37 Message: Logged In: YES user_id=370230 Originator: YES test_curses ^[[?1049h^[[1;50r^[(B^[[m^[[4l^[[?7h^[[50;1H^[[?1049l^M^[[?1l^[>test test_curses crashed -- : endwin() returned ERR -- Comment By: David Favor (dfavor) Date: 2007-06-06 10:36 Message: Logged In: YES user_id=370230 Originator: YES test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.00152) is more than 2 seconds more than expected (0.001) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 17:19 Message: Logged In: YES user_id=33168 Originator: NO test_timeout often fails depending on if the system the test connects to is available or not (ie, the test sucks). How does test_curses fail? What platform? BTW, you can use -u all. -- Comment By: David Favor (dfavor) Date: 2007-06-02 09:54 Message: Logged In: YES user_id=370230 Originator: YES These fixes should also be dropped into the 2.6 tree. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1733085 ] sqlite3 module trigger problem
Bugs item #1733085, was opened at 2007-06-07 23:36 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=1733085&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: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oinopion (oinopion) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3 module trigger problem Initial Comment: I and my team are building sqlite3 app and when used on Windows XP on Python 2.5.1 we get such an error: File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__ cur.executescript(scheme) OperationalError: near "NOT": syntax error while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql Bug is about those triggers at the end of file. On linux or with pysqlite2 imported instead of sqlite3 everything is OK. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1733085 ] sqlite3 module trigger problem
Bugs item #1733085, was opened at 2007-06-07 23:36 Message generated for change (Comment added) made by oinopion You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&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: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oinopion (oinopion) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3 module trigger problem Initial Comment: I and my team are building sqlite3 app and when used on Windows XP on Python 2.5.1 we get such an error: File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__ cur.executescript(scheme) OperationalError: near "NOT": syntax error while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql Bug is about those triggers at the end of file. On linux or with pysqlite2 imported instead of sqlite3 everything is OK. -- >Comment By: Oinopion (oinopion) Date: 2007-06-07 23:57 Message: Logged In: YES user_id=1282560 Originator: YES File Added: scheme.sql -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1733134 ] sqlite3.dll cannot be relocated
Bugs item #1733134, was opened at 2007-06-08 09:15 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=1733134&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3.dll cannot be relocated Initial Comment: >From Josh Ritter: A number of our Windows customers have an issue with the sqlite3 module included with Python 2.5.1 We've tracked the problem down to the sqlite3.dll included with the Python 2.5.1 distribition. It is stripped and thus cannot be relocated. This causes the following exception on computers where something is already loaded into the address the sqlite3.dll wants to use: File "sqlite3\__init__.pyc", line 24, in File "sqlite3\dbapi2.pyc", line 27, in ImportError: DLL load failed: Invalid access to memory location. I downloaded the latest sqlite3.dll from http://www.sqlite.org and this fixes the problem. (This dll isn't stripped) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733134&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1729277 ] SVNVERSION redefined during compilation
Bugs item #1729277, was opened at 2007-06-01 02:28 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&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: Build Group: Python 2.6 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj�n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. -- >Comment By: Kristj�n Valur (krisvale) Date: 2007-06-07 23:58 Message: Logged In: YES user_id=1262199 Originator: NO Applied the patch in change 55821, and backported to 25-maint in 55822 -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-05 17:23 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me, please apply. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-06-05 12:18 Message: Logged In: YES user_id=1262199 Originator: NO Here is a suggested patch. I don't have a linux setup to test with this, what do you think? Oh, and sorry for messing this up, I thought subwcrev was used on all platforms :( File Added: woo.patch -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-05 07:50 Message: Logged In: YES user_id=21627 Originator: NO The define is indeed needed on Windows. On a Windows installation, there is typically no svnversion binary. However, TortoiseSVN ships with a similar tool, calls subwcrev.exe, which does string interpolation on a template file. So the define in getbuildinfo is the template, and the link process creates a second C file (getbuildinfo1.c) which is then compiled and linked into the interpreter. As subwcrev.exe might not be installed, the build process used to pass a define SUBWCREV on the command line, which was a condition to the definition of SVNVERSION. As Kristjan removed the condition, the Unix build broke. -- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-04 19:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. -- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 19:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-06-04 09:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through sub
[ python-Bugs-1733184 ] slice type is unhashable
Bugs item #1733184, was opened at 2007-06-07 19:30 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=1733184&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: slice type is unhashable Initial Comment: Patch # 408326 is a "bug fix" that makes slice objects comparable but explicitly NOT hashable. I don't understand why Guido thinks this is the right behavior for them: they are immutable, have well-defined state, do not include references to mutable objects, and can be compared property for equality. Why shouldn't they be usable as dictionary keys? I have an application that really would like them to be usable as such. I know I can define a class Slice of my own .. but that seems so silly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733184&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1733085 ] sqlite3 module trigger problem
Bugs item #1733085, was opened at 2007-06-07 14:36 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&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: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oinopion (oinopion) >Assigned to: Gerhard Häring (ghaering) Summary: sqlite3 module trigger problem Initial Comment: I and my team are building sqlite3 app and when used on Windows XP on Python 2.5.1 we get such an error: File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__ cur.executescript(scheme) OperationalError: near "NOT": syntax error while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql Bug is about those triggers at the end of file. On linux or with pysqlite2 imported instead of sqlite3 everything is OK. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 21:05 Message: Logged In: YES user_id=33168 Originator: NO Gerhard, could you take a look? I don't have windows. -- Comment By: Oinopion (oinopion) Date: 2007-06-07 14:57 Message: Logged In: YES user_id=1282560 Originator: YES File Added: scheme.sql -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1733184 ] slice type is unhashable
Bugs item #1733184, was opened at 2007-06-07 21:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733184&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: slice type is unhashable Initial Comment: Patch # 408326 is a "bug fix" that makes slice objects comparable but explicitly NOT hashable. I don't understand why Guido thinks this is the right behavior for them: they are immutable, have well-defined state, do not include references to mutable objects, and can be compared property for equality. Why shouldn't they be usable as dictionary keys? I have an application that really would like them to be usable as such. I know I can define a class Slice of my own .. but that seems so silly. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-08 00:24 Message: Logged In: YES user_id=80475 Originator: NO FWIW, you have a easy work-around. Use repr(yourslice) as the dictionary key. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733184&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1733184 ] slice type is unhashable
Bugs item #1733184, was opened at 2007-06-07 19:30 Message generated for change (Comment added) made by lpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733184&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: slice type is unhashable Initial Comment: Patch # 408326 is a "bug fix" that makes slice objects comparable but explicitly NOT hashable. I don't understand why Guido thinks this is the right behavior for them: they are immutable, have well-defined state, do not include references to mutable objects, and can be compared property for equality. Why shouldn't they be usable as dictionary keys? I have an application that really would like them to be usable as such. I know I can define a class Slice of my own .. but that seems so silly. -- >Comment By: L. Peter Deutsch (lpd) Date: 2007-06-07 22:36 Message: Logged In: YES user_id=8861 Originator: YES I could probably live with that. However, there are other kinds of objects being used as keys in the same dictionary, and I can't just repr() them all, because it is not true that a == b implies repr(a) == repr(b). (E.g., a = 3, b = 3.0.) Practicalities aside, it just seems silly to me that a simple type like slice should have all the prerequisites for being hashable and yet isn't, especially when much more complex types like methods are both comparable and hashable. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-07 22:24 Message: Logged In: YES user_id=80475 Originator: NO FWIW, you have a easy work-around. Use repr(yourslice) as the dictionary key. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733184&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
