using pyodbc with python 3.2

[GoogleCodeExporter]

I have been wanting to switch to Python 3 but I need this library working with 
it to do so.

To that end, I checked out the v31 branch from github, applied updates from the 
master branch and the patch from issue 145 to it.  Attached is a patch which 
reflects those changes.

Also attached is test output from running the sqlserver tests against SQL 
Server 2005 Express SP3 running on Windows XP.  Using the FreeTDS 0.91 RC 
recently made available, there is only 1 failure and several errors which seem 
to need changes to the SQL in tests.

I have also run the mySQL tests against mySQL 5.5 running on Linux and all 
tests pass.

These tests were run from an ArchLinux x86_64 client machine.

Original issue reported on code.google.com by davidp.r...@gmail.com on 26 May 2011 at 2:49

Attachments:

• python32_patch.zip
• tests_log.zip

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Please try the recent 3.0.x builds or the source on the master branch.

I've included a FreeTDS set of tests that I've been testing with 0.9x.

Original comment by mkleehammer on 23 Dec 2011 at 7:15

• Changed state: Complete

[GoogleCodeExporter]

test configuration:

database server: SQL Server 2005 Express SP3 running on Windows XP.

database client 1 : Arch x86_64 Linux with unixODBC 2.3.1, freeTDS 0,91 Python 
2.7.2

results of running freetdstests.py

python:  2.7.2 (default, Jun 30 2011, 10:35:48) 
[GCC 4.6.1]
pyodbc:  3.0.2 
/home/updates/programming/pyodbc-3.0.2/pyodbc/build/lib.linux-x86_64-2.7/pyodbc.
so
odbc:    03.52
driver:  libtdsodbc.so 0.91
         supports ODBC version 03.50
os:      Linux
unicode: Py_Unicode=2 SQLWCHAR=2
======================================================================
ERROR: test_geometry_null_insert (__main__.FreeTDSTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "freetdstests.py", line 1145, in test_geometry_null_insert
    self.cursor.execute("create table t1(n int, v geometry)")
ProgrammingError: ('42000', '[42000] [FreeTDS][SQL Server]Column, parameter, or 
variable #2: Cannot find data type geometry. (2715) (SQLExecDirectW)')

----------------------------------------------------------------------
Ran 192 tests in 23.767s

FAILED (errors=1)

==========================

building against python 3.2 yields the following error (which I have not yet 
looked at)

programming/pyodbc-3.0.2/pyodbc/src/row.cpp -o 
build/temp.linux-x86_64-3.2/home/updates/programming/pyodbc-3.0.2/pyodbc/src/row
.o -Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for 
Ada/C/ObjC but not for C++ [enabled by default]
/home/updates/programming/pyodbc-3.0.2/pyodbc/src/row.cpp:386:1: error: invalid 
conversion from ‘PyObject* (*)(PyObject*, Py_ssize_t, Py_ssize_t) {aka 
_object* (*)(_object*, long int, long int)}’ to ‘void*’ [-fpermissive]

git status for the src directory shows:

# On branch master

Original comment by davidp.r...@gmail.com on 27 Dec 2011 at 4:32

[GoogleCodeExporter]

If I remember correctly, the geometry type was introduced in SQL Server 2008.  
I need to update the test to be ignored when not connected to 2008.

I am a bit baffled by the build error since I build a Fedora 64-bit version for 
my Linux tests.  (In fact, the RPM is available from the Downloads page.)  What 
compiler are you using?  I'm using gcc 4.6.1-9.  And do you have g++ installed?

Original comment by mkleehammer on 27 Dec 2011 at 4:42

• Changed state: Investigating

[GoogleCodeExporter]

For Python 3.2, I am compiling with: 

gcc (GCC) 4.6.2 20111125 (prerelease)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

which is the current version of gcc shipped with Arch.

All the other modules compile.

I will try building with the 4.6.1 compiler which I used to build the Python 2 
version of the library.

NOTE:  Arch does not use RPMs..

Original comment by davidp.r...@gmail.com on 27 Dec 2011 at 5:01

[GoogleCodeExporter]

Thanks. Meanwhile I'll see if I can get 4.6.2.

(And I know Arch doesn't use RPMs, I was just pointing out that I had built a 
64-bit Linux RPM yesterday, so it was something environmental, not fundamental. 
 I should have been clearer.)

Original comment by mkleehammer on 27 Dec 2011 at 5:04

[GoogleCodeExporter]

gcc 4.6.2 seems to have changed behavior such that the cast:

invalid conversion from ‘PyObject* (*)(PyObject*, Py_ssize_t, Py_ssize_t) 
{aka _object* (*)(_object*, long int, long int)}’ to ‘void

is an error instead of a warning.  Adding -fpermissive to the compile changes 
it back to a warning so it will build.

Original comment by davidp.r...@gmail.com on 27 Dec 2011 at 6:28

[GoogleCodeExporter]

NOTE:  using -fpermissive is not a good solution since it enables other 
behaviors which people may not want.

Original comment by davidp.r...@gmail.com on 27 Dec 2011 at 8:33

[GoogleCodeExporter]

I have just tried to build the pyodbc 3.0.2 this time with a newly built 
vanilla gcc 4.6.1 compiler and I get the same error message as above about an 
invalid conversion.

I wonder if Fedora has patched their version of the compiler ??

Original comment by davidp.r...@gmail.com on 28 Dec 2011 at 3:43

[GoogleCodeExporter]

I think I see what is going on.

The compile error happens when assigning values to the members of a 
PySequenceMethods structure instance.  The particular problem is with the 
sq_slice field which in row.cpp line 382 is of type Row_slice.  However, in the 
actual PySequenceMethods structure definition in object.h line 254 this field 
is now a void*.  So, it seems the fix is to either do a cast to void* or assign 
a 0 to the value if the void* type means the value of this field is not used 
any more.

Original comment by davidp.r...@gmail.com on 28 Dec 2011 at 4:44

[GoogleCodeExporter]

Fixed in 3.0.3

The sq_slice field was apparently deprecated, so you will find it is now 
was_sq_slice.  The function pointer was then changed to a void* which gcc does 
not like.  Slicing still works, but is implemented differently.

The new slicing, which I added in 3.0.0, may keep it from building for 2.4 and 
2.5.  I may have to put the Row_slice function back for those versions only.

Thanks for the report, I've now updated by Linux build machine to Fedora 16 
with gcc 4.6.2.

Original comment by mkleehammer on 28 Dec 2011 at 10:25

• Changed state: Complete

[GoogleCodeExporter]

Thanks for fixing this !

Now when I build from source after doing a git pull, the egg file is named: 
pyodbc-3.0.4_beta01-py3.2.egg-info instead of 3.0.3 version number.

did I miss something?

Original comment by davidp.r...@gmail.com on 29 Dec 2011 at 3:40

[GoogleCodeExporter]

tl;dr: You are building from one commit after 3.0.3.  Backup a commit.

The version number is derived from the git tags, in particular the output of 
"git describe --tags".

In this case, the describe output starts with "3.0.3-1" meaning there is 1 
commit after the 3.0.3 tag on this branch.  I change the final number since you 
can't be building 3.0.3, it is finalized and tagged, so you must be starting on 
3.0.4.  Therefore: 3.0.4-beta01.

You can get the details by looking at the "python setup.py version" command.

To build 3.0.3, backup one commit (git reset HEAD~1 --hard)

Original comment by mkleehammer on 29 Dec 2011 at 4:00