My favorites | Sign in
Project Home Downloads Wiki
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 178: using pyodbc with python 3.2
1 person starred this issue and may be notified of changes. Back to list
Status:  Complete
Owner:  ----
Closed:  Dec 2011


 
Reported by davidp.r...@gmail.com, May 26, 2011
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.

 

python32_patch.zip
3.5 KB   Download
tests_log.zip
1.1 KB   Download
Dec 23, 2011
Project Member #2 mkleehammer
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.

Status: Complete
Dec 27, 2011
#3 davidp.r...@gmail.com

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





Dec 27, 2011
Project Member #4 mkleehammer
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?
Status: Investigating
Dec 27, 2011
#5 davidp.r...@gmail.com

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..


Dec 27, 2011
Project Member #6 mkleehammer
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.)

Dec 27, 2011
#7 davidp.r...@gmail.com

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.


Dec 27, 2011
#8 davidp.r...@gmail.com

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

Dec 28, 2011
#9 davidp.r...@gmail.com

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 ??
Dec 28, 2011
#10 davidp.r...@gmail.com
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.
Dec 28, 2011
Project Member #11 mkleehammer
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.
Status: Complete
Dec 29, 2011
#12 davidp.r...@gmail.com
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?
Dec 29, 2011
Project Member #13 mkleehammer
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)


Powered by Google Project Hosting