[ python-Bugs-1574310 ] os.popen with os.close gives error message
Bugs item #1574310, was opened at 2006-10-10 09:45
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=1574310&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: dtrosset (dtrosset)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen with os.close gives error message
Initial Comment:
Given the following code:
import os
child_stdin = os.popen("cat -", "w")
old_stdout = os.dup(1)
os.close(child_stdin.fileno())
print "foo"
os.dup2(old_stdout, 1)
os.close(old_stdout)
I got these different results depending on the version
of python I am using.
$ python2.4 -V
Python 2.4.4c0
$ python2.4 test.py
foo
close failed: [Errno 9] Bad file descriptor
$ python2.3 -V
Python 2.3.5
$ python2.3 test/new/test.py
foo
My .02$ guess is that underlying file descriptor of
child_stdin being closed, when trying to delete this
object, it tries again to close it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574310&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1573854 ] sqlite3 documentation on rowcount is contradictory
Bugs item #1573854, was opened at 2006-10-09 18:18 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573854&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: Python 2.5 Status: Open Resolution: None >Priority: 3 Submitted By: Seo Sanghyeon (sanxiyn) >Assigned to: Gerhard Häring (ghaering) Summary: sqlite3 documentation on rowcount is contradictory Initial Comment: http://docs.python.org/lib/sqlite3-Cursor-Objects.html says: For SELECT statements, rowcount is always None because we cannot determine the number of rows a query produced until all rows were fetched. As required by the Python DB API Spec, the rowcount attribute "is -1 in case no executeXX() has been performed on the cursor or the rowcount of the last operation is not determinable by the interface". Clearly, both can't be true. My experiment showed that rowcount is set to -1, not None. I suggest rewriting this to something like: As required by the Python DB API Spec, the rowcount attribute "is -1 in case no executeXX() has been performed on the cursor or the rowcount of the last operation is not determinable by the interface". This includes SELECT statements, because we cannot determine the number of rows a query produced until all rows are fetched. -- >Comment By: Gerhard Häring (ghaering) Date: 2006-10-10 12:04 Message: Logged In: YES user_id=163326 Thanks for the bug report. I will perform the suggested change. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573854&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1574584 ] Error with callback function and as_parameter with NumPy ndp
Bugs item #1574584, was opened at 2006-10-10 17:11
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=1574584&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
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with callback function and as_parameter with NumPy ndp
Initial Comment:
I posted to the ctypes-users mailing list about this
problem, but SourceForge failed to make that post and
its replies available in the ctypes-users archive, so
I'm repeating it here.
I'm using NumPy with ctypes. I would like to create a
callback function that calls into Python, allocates a
NumPy array and returns a suitable pointer to the C code.
NumPy has a function called ndpointer that allows one
to specify some details of NumPy arrays when dealing
with argtypes. This function also takes care of
extracting the array's data pointer.
Details here:
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/ctypeslib.py
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/core/_internal.py
Creating a callback function as follows works:
stuff = []
import numpy
def allocator1():
x = numpy.array([...], dtype='f4')
stuff.append(x)
return x.ctypes.data_as(POINTER(c_float))
CFUNCTYPE(POINTER(c_float))(allocator1)
However, if one adds ndpointer to the mix, an error occurs:
stuff = []
import numpy
def allocator2():
x = numpy.array([...], dtype='f4')
stuff.append(x)
return x
CFUNCTYPE(numpy.ctypeslib.ndpointer('f4'))(allocator2)
The error is:
SystemError: NULL result without error in PyObject_Call
Thomas Heller has a patch for this issue.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574584&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1574588 ] ctypes: Pointer-to-pointer unchanged in callback
Bugs item #1574588, was opened at 2006-10-10 17:16
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=1574588&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
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes: Pointer-to-pointer unchanged in callback
Initial Comment:
This problem is from another post I made to
ctypes-users that didn't show up in the ctypes-users
archive.
C function:
extern CALLBACK_API void foo(void(*callback)(void**)) {
void* p = 123;
printf("foo calling callback\n");
callback(&p);
printf("callback returned in foo\n");
printf("p = 0x%p\n", p);
}
I figured that while I try to find out why returning
c_void_p from a callback gives an error, I might as
well return the address via a pointer to a pointer.
In the Python code I have:
import sys
print sys.version
from ctypes import *
x_t = c_int*10
x = x_t()
def callback(ptr):
print x
print ptr
ptr.contents = cast(addressof(x), c_void_p)
print ptr.contents
#lib = cdll['libcallback.so']
lib = cdll['callback.dll']
lib.foo.argtypes = [CFUNCTYPE(None, POINTER(c_void_p))]
lib.foo(lib.foo.argtypes[0](callback))
Output when I running this script under Python 2.4.3
with ctypes 1.0.0 (I get identical results with Python
2.5 and ctypes 1.0.1):
2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)]
foo calling callback
<__main__.c_long_Array_10 object at 0x00963E90>
c_void_p(10048496)
callback returned in foo
p = 0x007B
For some reason, the value I assigned to ptr.contents
isn't present when we return to the C code.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574588&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1574593 ] ctypes: Returning c_void_p from callback doesn't work
Bugs item #1574593, was opened at 2006-10-10 17:18
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=1574593&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
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes: Returning c_void_p from callback doesn't work
Initial Comment:
C code:
extern CALLBACK_API void* foo(void*(*callback)()) {
printf("foo calling callback\n");
callback();
printf("callback returned in foo\n");
}
callback.py contains:
import sys
print sys.version
from ctypes import *
def callback(*args):
return c_void_p()
#lib = cdll['libcallback.so']
lib = cdll['callback.dll']
lib.foo.argtypes = [CFUNCTYPE(c_void_p)]
lib.foo(lib.foo.argtypes[0](callback))
With Python 2.4.3 and ctypes 1.0.0 + Thomas Heller's
patch for another issue (which doesn't seem to affect
this situation, but anyway) I get the following error:
2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)]
foo calling callback
Traceback (most recent call last):
File "source/callbacks.c", line 216, in 'converting
callback result'
TypeError: cannot be converted to pointer
Exception in None ignored
callback returned in foo
With Python 2.5 and ctypes 1.0.1 I get:
2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
bit (Intel)]
foo calling callback
Traceback (most recent call last):
File "\loewis\25\python\Modules\_ctypes\callbacks.c",
line 216, in
'converting callback result'
TypeError: cannot be converted to pointer
Exception in ignored
callback returned in foo
Returning a Python integer from callback() doesn't
cause an error to be raised.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574593&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Bugs item #1494314, was opened at 2006-05-24 23:51 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Smith (mlrsmith) Assigned to: Anthony Baxter (anthonybaxter) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-11 11:46 Message: Logged In: YES user_id=29957 This is applied and will be in 2.3.3c1 -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-12 03:21 Message: Logged In: YES user_id=29957 Re-opening to remind myself to apply this to release24-maint for the eventual 2.4.4 release. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-11 13:52 Message: Logged In: YES user_id=29957 Applied. Patch will be in 2.5b2 (to be released shortly). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 12:53 Message: Logged In: YES user_id=33168 Anthony checked this in to 2.5 as 50567. I will backport at least part of it later. -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-10 15:47 Message: Logged In: YES user_id=21627 The patch is fine, please apply. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 09:57 Message: Logged In: YES user_id=33168 I meant I don't think we *care* in this case (not can). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 09:55 Message: Logged In: YES user_id=33168 I think you're right Martin. Looking at what it means to have a broken poll, I don't think we can in this instance. So I removed all refs to HAVE_BROKEN_POLL. What do you think of the new version? -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-08 01:50 Message: Logged In: YES user_id=21627 The __APPLE__ stuff looks wrong in file 184131. You would have to use selectmodule.c:select_have_broken_poll at run-time to be sure you can use poll(2) on OS X (you can use it on 10.4, but can't on 10.3, IIRC). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-07 16:10 Message: Logged In: YES user_id=33168 I've added a more complete patch (against 2.5, hopefully applies to 2.4 too). It cleans up some things and adds support for SSL sockets too. Can people please review/test this? I manually tested this with regular sockets and it seemed to work. All the tests pass, but this is somewhat tricky. I hate the duplicated code between socket and ssl modules, but added to it. It would be great to clean this up for 2.6. If you are forced to use select with a high socket, the exception on connect is operation in progress rather than can't select on socket. I guess that's ok, it doesn't actually change the existing behaviour. That would have been more involved and I'm not sure it's worth it. --
[ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Bugs item #1494314, was opened at 2006-05-24 06:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Smith (mlrsmith) Assigned to: Anthony Baxter (anthonybaxter) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-10 19:40 Message: Logged In: YES user_id=33168 I assume 2.3.3c1 means 2.4.4c1. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-10 18:46 Message: Logged In: YES user_id=29957 This is applied and will be in 2.3.3c1 -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-11 10:21 Message: Logged In: YES user_id=29957 Re-opening to remind myself to apply this to release24-maint for the eventual 2.4.4 release. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-10 20:52 Message: Logged In: YES user_id=29957 Applied. Patch will be in 2.5b2 (to be released shortly). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 19:53 Message: Logged In: YES user_id=33168 Anthony checked this in to 2.5 as 50567. I will backport at least part of it later. -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-09 22:47 Message: Logged In: YES user_id=21627 The patch is fine, please apply. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-09 16:57 Message: Logged In: YES user_id=33168 I meant I don't think we *care* in this case (not can). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-09 16:55 Message: Logged In: YES user_id=33168 I think you're right Martin. Looking at what it means to have a broken poll, I don't think we can in this instance. So I removed all refs to HAVE_BROKEN_POLL. What do you think of the new version? -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-07 08:50 Message: Logged In: YES user_id=21627 The __APPLE__ stuff looks wrong in file 184131. You would have to use selectmodule.c:select_have_broken_poll at run-time to be sure you can use poll(2) on OS X (you can use it on 10.4, but can't on 10.3, IIRC). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 23:10 Message: Logged In: YES user_id=33168 I've added a more complete patch (against 2.5, hopefully applies to 2.4 too). It cleans up some things and adds support for SSL sockets too. Can people please review/test this? I manually tested this with regular sockets and it seemed to work. All the tests pass, but this is somewhat tricky. I hate the duplicated code between socket and ssl modules, but added to it. It would be great to clean this up for 2.6. If you are forced to use select with a high socket, the exception on connect is operation in progress rather than can't select on socket.
[ python-Bugs-1575020 ] Request wave support > 16 bit samples
Bugs item #1575020, was opened at 2006-10-11 11: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=1575020&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: Murray Lang (murraylang) Assigned to: Nobody/Anonymous (nobody) Summary: Request wave support > 16 bit samples Initial Comment: May I request that the wave library support audio formats greater than 16 bit. I am hoping to use GNU Radio (http://www.gnu.org/software/gnuradio/) Python software with HPSDR (http://hpsdr.org/) hardware, but the HPSDR audio is 24 bit. The extra dynamic range is required for weak signal work. Many audio cards are now coming on the market with 24 bit capability. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575020&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
