Re: Awkwardness of C API for making tuples
John Machin wrote:
Dave Opstad wrote:
One of the functions in a C extension I'm writing needs to return a
tuple of integers, where the length of the tuple is only known at
runtime. I'm currently doing a loop calling PyInt_FromLong to make
the
integers,
What is the purpose of this first loop?
In what variable-length storage are you storing these (Python) integers
during this first loop? Something you created with (a) PyMem_Malloc (b)
malloc (c) alloca (d) your_own_malloc?
then PyTuple_New, and finally a loop calling PyTuple_SET_ITEM
to set the tuple's items. Whew.
Whew indeed.
Does anyone know of a simpler way? I can't use Py_BuildValue because
I
don't know at compile-time how many values there are going to be. And
there doesn't seem to be a PyTuple_FromArray() function.
If I'm overlooking something obvious, please clue me in!
1. Determine the length of the required tuple; this may need a loop,
but only to _count_ the number of C longs that you have.
2. Use PyTuple_New.
3. Loop to fill the tuple, using PyInt_FromLong and PyTuple_SetItem.
Much later, after thoroughly testing your code, gingerly change
PyTuple_SetItem to PyTuple_SET_ITEM. Benchmark the difference. Is it
anywhere near what you saved by cutting out the store_in_temp_array
thing in the first loop?
Shouldn't something like this (uncompiled) do what you want?
- Dave
PyObject *PyTuple_FromArray(int *values, int num_values)
{
PyObject *tuple;
int i;
tuple = PyTuple_New(num_values);
if (tuple == NULL)
return NULL;
for (i = 0; i < num_values; i++) {
PyObject *obj;
obj = PyInt_FromLong(value[i]);
if (obj == NULL
|| PyTuple_SetItem(tuple, i, obj) != 0) {
Py_DECREF(tuple);
return NULL;
}
}
return tuple;
}
--
http://www.object-craft.com.au
--
http://mail.python.org/mailman/listinfo/python-list
Sybase module 0.37pre1 released
WHAT IS IT:
The Sybase module provides a Python interface to the Sybase relational
database system. It supports all of the Python Database API, version
2.0 with extensions.
NOTES:
This release contains a number of small bugfixes and patches received
from users.
I have been unable to find the source of the memory leak reported here:
http://www.object-craft.com.au/pipermail/python-sybase/2004-December/000346.html
The test program I wrote follows:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
import sys
import Sybase
db = Sybase.connect(..., auto_commit=True)
db.execute('''
if exists (select name from sysobjects where name = "sp_test_leak")
begin
drop procedure sp_test_leak
end
''')
db.execute('''
create procedure sp_test_leak
@arg int
as
select @arg
''')
for i in range(200):
for j in range(1000):
c = db.cursor()
c.callproc('sp_test_leak', {'@arg': 12345 })
sys.stdout.write('%3d\r' % i)
sys.stdout.flush()
sys.stdout.write('\n')
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If someone is able to modify this and come up with a leaking result I
am interested in working on the fix.
You can build for FreeTDS like this:
python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
python setup.py install
The module is available here:
http://www.object-craft.com.au/projects/sybase/download/sybase-0.37pre1.tar.gz
The module home page is here:
http://www.object-craft.com.au/projects/sybase/
CHANGES SINCE 0.36:
* Cursor output parameters now work when parameters are passed as a
sequence.
* Output parameters now work for FreeTDS 0.62.4.
1> create procedure sp_test_output
2> @num int, @result int output
3> as
4> select @result = @num
5> go
params = c.callproc('sp_test_output', {'@num': 12345,
'@result': Sybase.OUTPUT(1)})
print params['@result']
* The CS_STATUS_RESULT result set is now consumed internally in the
Cursor and does not appear in the result sets consumed by the fetch
and nextset methods.
The return value from the stored procedure is available in the
.return_status member of the Cursor. It will only contain a
meaningful value once all of the row result sets have been consumed.
Note that this does not work with FreeTDS 0.62.4. The return_status
seems to always be 0. Research shows that the problem is probably
in the CT emulation layer as tsql displays the correct value, but
sqsh displays 0.
* Output hook patch from Ty Sarna has been applied.
* Applied patch from Andre Sedinin to improve error handling.
* Improved detection of SYBASE_OCS.
- Dave
--
http://www.object-craft.com.au
--
http://mail.python.org/mailman/listinfo/python-list
Re: passing a socket to a spawned process.
Martin C.Atkins wrote: I have (finally!) put a package up on our website that provides a Python module for sending file descriptors down Unix-domain sockets, on Linux. See the first item under: http://www.mca-ltd.com/index.php?PAGE=resources/home.php Please let me know of any problems, obvious omissions, etc... BTW: I just found out about bindd (see the README), and could probably clean the code up from the examples in its sourcecode, but the current version of fdcred works for me! Sorry it has taken so long! I notice that you have used the LGPL for your code. Could you be convinced to use a Python style license? This would mean that some time in the (hopefully not too distant) future the code could be added to the standard socket module. - Dave -- http://www.object-craft.com.au -- http://mail.python.org/mailman/listinfo/python-list
Sybase module 0.37pre2 released
WHAT IS IT:
The Sybase module provides a Python interface to the Sybase relational
database system. It supports all of the Python Database API, version
2.0 with extensions.
NOTES:
This release contains a number of small bugfixes and patches received
from users.
I have been unable to find the source of the memory leak reported here:
http://www.object-craft.com.au/pipermail/python-sybase/2004-December/000346.html
The test program I wrote follows:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
import sys
import Sybase
db = Sybase.connect(..., auto_commit=True)
db.execute('''
if exists (select name from sysobjects where name = "sp_test_leak")
begin
drop procedure sp_test_leak
end
''')
db.execute('''
create procedure sp_test_leak
@arg int
as
select @arg
''')
for i in range(200):
for j in range(1000):
c = db.cursor()
c.callproc('sp_test_leak', {'@arg': 12345 })
sys.stdout.write('%3d\r' % i)
sys.stdout.flush()
sys.stdout.write('\n')
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If someone is able to modify this and come up with a leaking result I
am interested in working on the fix.
You can build for FreeTDS like this:
python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
python setup.py install
The module is available here:
http://www.object-craft.com.au/projects/sybase/download/sybase-0.37pre1.tar.gz
The module home page is here:
http://www.object-craft.com.au/projects/sybase/
CHANGES SINCE 0.36:
* Cursor state initialisation fix from Skip Montanaro.
* Callback declaration fix on Windows from Vadim Beloborodov.
* Cursor output parameters now work when parameters are passed as a
sequence.
* Output parameters now work for FreeTDS 0.62.4.
1> create procedure sp_test_output
2> @num int, @result int output
3> as
4> select @result = @num
5> go
params = c.callproc('sp_test_output', {'@num': 12345,
'@result': Sybase.OUTPUT(1)})
print params['@result']
* The CS_STATUS_RESULT result set is now consumed internally in the
Cursor and does not appear in the result sets consumed by the fetch
and nextset methods.
The return value from the stored procedure is available in the
.return_status member of the Cursor. It will only contain a
meaningful value once all of the row result sets have been consumed.
Note that this does not work with FreeTDS 0.62.4. The return_status
seems to always be 0. Research shows that the problem is probably
in the CT emulation layer as tsql displays the correct value, but
sqsh displays 0.
* Output hook patch from Ty Sarna has been applied.
* Applied patch from Andre Sedinin to improve error handling.
* Improved detection of SYBASE_OCS.
- Dave
--
http://www.object-craft.com.au
--
http://mail.python.org/mailman/listinfo/python-list
Re: [DB-SIG] Sybase module 0.37pre2 released
Dave Cole wrote: The module is available here: http://www.object-craft.com.au/projects/sybase/download/sybase-0.37pre1.tar.gz Ooops. Make that: http://www.object-craft.com.au/projects/sybase/download/sybase-0.37pre2.tar.gz - Dave -- http://www.object-craft.com.au -- http://mail.python.org/mailman/listinfo/python-list
Sybase module 0.37 released
WHAT IS IT:
The Sybase module provides a Python interface to the Sybase relational
database system. It supports all of the Python Database API, version
2.0 with extensions.
NOTES:
The 0.37 release is identical to 0.37pre3 as no problems were reported
with the prerelease.
This release contains a number of small bugfixes and patches received
from users.
I have been unable to find the source of the memory leak reported here:
http://www.object-craft.com.au/pipermail/python-sybase/2004-December/000346.html
The test program I wrote follows:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
import sys
import Sybase
db = Sybase.connect(..., auto_commit=True)
db.execute('''
if exists (select name from sysobjects where name = "sp_test_leak")
begin
drop procedure sp_test_leak
end
''')
db.execute('''
create procedure sp_test_leak
@arg int
as
select @arg
''')
for i in range(200):
for j in range(1000):
c = db.cursor()
c.callproc('sp_test_leak', {'@arg': 12345 })
sys.stdout.write('%3d\r' % i)
sys.stdout.flush()
sys.stdout.write('\n')
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If someone is able to modify this and come up with a leaking result I
am interested in working on the fix.
You can build for FreeTDS like this:
python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
python setup.py install
The module is available here:
http://www.object-craft.com.au/projects/sybase/download/sybase-0.37pre3.tar.gz
The module home page is here:
http://www.object-craft.com.au/projects/sybase/
CHANGES SINCE 0.36:
* Fix FreeTDS compilation and rearrange header includes to remove warnings.
* Cursor state initialisation fix from Skip Montanaro.
* Callback declaration fix on Windows from Vadim Beloborodov.
* Cursor output parameters now work when parameters are passed as a
sequence.
* Output parameters now work for FreeTDS 0.62.4.
1> create procedure sp_test_output
2> @num int, @result int output
3> as
4> select @result = @num
5> go
params = c.callproc('sp_test_output', {'@num': 12345,
'@result': Sybase.OUTPUT(1)})
print params['@result']
* The CS_STATUS_RESULT result set is now consumed internally in the
Cursor and does not appear in the result sets consumed by the fetch
and nextset methods.
The return value from the stored procedure is available in the
.return_status member of the Cursor. It will only contain a
meaningful value once all of the row result sets have been consumed.
Note that this does not work with FreeTDS 0.62.4. The return_status
seems to always be 0. Research shows that the problem is probably
in the CT emulation layer as tsql displays the correct value, but
sqsh displays 0.
* Output hook patch from Ty Sarna has been applied.
* Applied patch from Andre Sedinin to improve error handling.
* Improved detection of SYBASE_OCS.
--
http://www.object-craft.com.au
--
http://mail.python.org/mailman/listinfo/python-list
