From subscriptions@gnumed.net Fri Nov 1 04:05:47 2002 From: subscriptions@gnumed.net (Horst Herb) Date: Fri, 01 Nov 2002 15:05:47 +1100 Subject: [DB-SIG] Dictionaries Pass By Reference? References: <4FFD1CA10E16DE43AEDA0AB7B13B7293AB2941@exchange.pfloans.com> Message-ID: <3DC1FD9B.3060209@gnumed.net> Tom Rabaut wrote: > I'm under the understanding that dictionaries are pass by reference in python, but it doesn't seem to be working for me. I'm declaring the dictionary in main then passing it to a function member of a module where it is populated, but when I attempted to use it, it is still empty in the main program. Off topic, but here you go: IDLE 0.8 -- press F1 for help >>> def filldic(dic): dic[1] = 1 >>> def mainfunc(): dic = {} filldic(dic) print dic[1] >>> mainfunc() 1 Works. Check your code. Horst From dyoo@hkn.eecs.berkeley.edu Fri Nov 1 08:23:13 2002 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Fri, 1 Nov 2002 00:23:13 -0800 (PST) Subject: [DB-SIG] Dictionaries Pass By Reference? In-Reply-To: <4FFD1CA10E16DE43AEDA0AB7B13B7293AB2941@exchange.pfloans.com> Message-ID: On Thu, 31 Oct 2002, Tom Rabaut wrote: > I'm under the understanding that dictionaries are pass by reference in > python, but it doesn't seem to be working for me. I'm declaring the > dictionary in main then passing it to a function member of a module > where it is populated, but when I attempted to use it, it is still empty > in the main program. Hi Tom, You may want to ask your question on the Python-Tutor mailing list instead; db-sig is more focused on relational database issues. Python-tutor is a mailing list dedicated to help people learn more about programming. If you're interested, you can find out more information about Tutor here: http://mail.python.org/mailman/listinfo/tutor I hope this helps! From duaneh@connexus.net.au Sat Nov 2 06:01:57 2002 From: duaneh@connexus.net.au (Duane and Karen) Date: Sat, 2 Nov 2002 17:01:57 +1100 Subject: [DB-SIG] Dictionaries Pass By Reference? Message-ID: <000001c28235$7d994730$2d59decb@custard> This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C28291.B10B45D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by power.connexus.net.au id gA261gJM098250 Sorry, I actually replied to the questioner's address, so I'm hoping I se= nt this to the right place. Following is a transcript of my earlier reply (Sorry Tom.) " I actually bypassed that and passed a dictionary like so.. =A0 ### code start ### def get_new_dict_values(dict): =A0=A0=A0 # change values =A0=A0=A0 dict['key1'] =3D 'new value 1' =A0=A0=A0 dict['key3'] =3D 'new key added' =A0=A0=A0 return dict =A0 def main(): =A0=A0=A0 # set up initial dicitonary =A0=A0=A0 dict =3D {} =A0=A0=A0 dict['key1'] =3D 'initial value 1' =A0=A0=A0 dict['key2'] =3D 'initial value 2' =A0=A0=A0 print dict =A0=A0=A0 dict =3D get_new_dict_values(dict) =A0=A0=A0 print dict =A0=A0=A0 return =A0 main() ### code end ### =A0 The reason I would do this is because Python is a pure object oriented language and as such it will reset the original dictionary object to the = new one, which is just a manipulated result of the one you passed. I cannot s= ee any ByReference (like VB) unless you make the dictionary global like the following code, in which case you would not have to pass it... (Though th= at is just my opinion and I have yet to find the facts, but this seems logic= al for the language. :) ) =A0 ### code start ### =A0 def get_new_dict_values(): =A0=A0=A0 # change values =A0=A0=A0 global dict =A0=A0=A0 dict['key1'] =3D 'new value 1' =A0=A0=A0 dict['key3'] =3D 'new key added' =A0=A0=A0 return =A0 def main(): =A0=A0=A0 # set up initial dicitonary =A0=A0=A0 global dict =A0=A0=A0 dict['key1'] =3D 'initial value 1' =A0=A0=A0 dict['key2'] =3D 'initial value 2' =A0=A0=A0 print dict =A0=A0=A0 dict =3D get_new_dict_values() =A0=A0=A0 print dict =A0=A0=A0 return =A0 ### Set global dictionary =A0 dict =3D {} =A0 main() =A0 ### code end ### =A0 Hope this helps, =A0 Duane. " Duane Hennessy Glen Iris, Victoria, Australia =A0 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 10/9/2002 ------=_NextPart_000_0001_01C28291.B10B45D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sorry, = I actually=20 replied to the questioner's address, so I'm hoping I sent this to the = right=20 place. Following is a transcript of my earlier reply (Sorry=20 Tom.)
"
I = actually bypassed=20 that and passed a dictionary like so..
 
### = code start=20 ###
def get_new_dict_values(dict):
    # change=20 values
    dict['key1'] =3D 'new value = 1'
   =20 dict['key3'] =3D 'new key added'
    return=20 dict
 
def=20 main():
    # set up initial = dicitonary
   =20 dict =3D {}
    dict['key1'] =3D 'initial value=20 1'
    dict['key2'] =3D 'initial value = 2'
   =20 print dict
    dict =3D=20 get_new_dict_values(dict)
    print = dict
   =20 return
 
main()
### code=20 end ###
 
The = reason I would=20 do this is because Python is a pure object oriented language and as such = it will=20 reset the original dictionary object to the new one, which is just a = manipulated=20 result of the one you passed. I cannot see any ByReference (like VB) = unless you=20 make the dictionary global like the following code, in which case you = would not=20 have to pass it... (Though that is just my opinion and I have yet to = find the=20 facts, but this seems logical for the language. :) )
 
### = code start=20 ###
 
def=20 get_new_dict_values():
    # change=20 values
    global dict
    = dict['key1'] =3D=20 'new value 1'
    dict['key3'] =3D 'new key=20 added'
    return
 
def=20 main():
    # set up initial = dicitonary
   =20 global dict
    dict['key1'] =3D 'initial value=20 1'
    dict['key2'] =3D 'initial value = 2'
   =20 print dict
    dict =3D=20 get_new_dict_values()
    print = dict
   =20 return
 
### = Set global=20 dictionary
 
dict = =3D=20 {}
 
main()
 
### = code end=20 ###
 
Hope = this=20 helps,
 
Duane.
"
Duane Hennessy
Glen Iris, Victoria, = Australia
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.401 / Virus Database: 226 - Release Date: 10/9/2002

------=_NextPart_000_0001_01C28291.B10B45D0-- From ocollioud@nagora.com Sun Nov 3 22:01:38 2002 From: ocollioud@nagora.com (Olivier Collioud) Date: Sun, 03 Nov 2002 23:01:38 +0100 Subject: [DB-SIG] 'long' object has no attribute 'fetchall' Message-ID: <3DC59CC2.5020604@nagora.com> Hi, I am new to both Python and MySQL... but, please, help me cause I'm really stuck. Below is my piece of code: import MySQLdb db = MySQLdb.Connection('localhost','','','test') cursor = db.cursor() cursor = cursor.execute('SELECT * FROM articles') cursor.fetchall() Error is: AttributeError: 'long' object has no attribute 'fetchall' I use: Windows 2000 MySQL 3.23.53 (mysqld-max-nt) Python 2.2.2 MySQL-python-0.9.2.win32-py2.2 Thaks, Olivier. From magnus@thinkware.se Sun Nov 3 22:33:30 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Sun, 03 Nov 2002 23:33:30 +0100 Subject: [DB-SIG] 'long' object has no attribute 'fetchall' In-Reply-To: <3DC59CC2.5020604@nagora.com> Message-ID: <5.1.0.14.0.20021103232719.043e9920@www.thinkware.se> At 23:01 2002-11-03 +0100, you wrote: >cursor = db.cursor() >cursor = cursor.execute('SELECT * FROM articles') You loose your cursor here, as you reassign the variable called cursor to the return value from the execute call. The result of cursor.execute() is the number of affected rows if my memory serves me right. Just change that line of code to cursor.execute('SELECT * FROM articles') and you will be fine. If you wish, you can take care of the return value, but be certain to use another variable for that. rowCount = cursor.execute('SELECT * FROM articles') print rowCount, "row(s) found" >cursor.fetchall() > >Error is: >AttributeError: 'long' object has no attribute 'fetchall' >Thaks, What's a Thak? ;) -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From haering_postgresql@gmx.de Sun Nov 3 22:31:33 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Sun, 3 Nov 2002 23:31:33 +0100 Subject: [DB-SIG] 'long' object has no attribute 'fetchall' In-Reply-To: <3DC59CC2.5020604@nagora.com> References: <3DC59CC2.5020604@nagora.com> Message-ID: <20021103223133.GA2971@lilith.ghaering.test> * Olivier Collioud [2002-11-03 23:01 +0100]: > cursor = cursor.execute('SELECT * FROM articles') > cursor.fetchall() > > Error is: > AttributeError: 'long' object has no attribute 'fetchall' cursor.execute returns the number of rows affected. So the line cursor = cursor.execute('SELECT * FROM articles') rebinds the name cursor to a long value with the number of changed rows. Don't do that. Simply do: cursor.execute('SELECT * FROM articles') instead. -- Gerhard From ocollioud@nagora.com Mon Nov 4 08:37:26 2002 From: ocollioud@nagora.com (Olivier Collioud) Date: Mon, 04 Nov 2002 09:37:26 +0100 Subject: [DB-SIG] 'long' object has no attribute 'fetchall' References: <3DC59CC2.5020604@nagora.com> Message-ID: <3DC631C6.1020801@nagora.com> Many tha(n)ks Gerhard and Magnus See you very soon on this list ;-) Do you know why I receive each message twice from the list ? From jekabs.andrusaitis@tietoenator.com Mon Nov 4 08:42:11 2002 From: jekabs.andrusaitis@tietoenator.com (Jekabs Andrushaitis) Date: Mon, 4 Nov 2002 10:42:11 +0200 Subject: [DB-SIG] Duplicate mails In-Reply-To: <3DC631C6.1020801@nagora.com> Message-ID: <000e01c283de$11f06220$262a949f@konts.lv> There might be several reasons... 1) You might be subscribed to list from different email addresses...; 2) You might have misconfigured your mail program's filtering rules (can be easily done in Outlook!:); 3) If you do not get all the messages in number of two, but just replies to your own mails, people might be using Reply to both yourself and the list :) Jekabs Andrushaitis Senior system analyst TietoEnator Financial Solutions 41 Lacplesa Str. Riga, LV-1011, Latvia Tel: +371 7286660 Fax: +371 7243000 E-mail: jekabs.andrusaitis@tietoenator.com From magnus@thinkware.se Mon Nov 4 09:51:01 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Mon, 04 Nov 2002 10:51:01 +0100 Subject: [DB-SIG] Duplicate mails In-Reply-To: <000e01c283de$11f06220$262a949f@konts.lv> References: <3DC631C6.1020801@nagora.com> Message-ID: <5.1.0.14.0.20021104103835.043ec318@www.thinkware.se> At 10:42 2002-11-04 +0200, Jekabs Andrushaitis wrote: >3) If you do not get all the messages in number of two, but just replies to >your own mails, people might >be using Reply to both yourself and the list :) In that case only one of the mails will have the "DB-SIG" footer in the bottom. It should also be evident from the headers. I think it's very reasonable to do "Reply to all" on direct questions like this. These duplicates isn't a big problem for the recipient, once you understand them. I'm not sure if you can post to this list without being subscribed, but you can certainly have daily disgest mode set, in which case you won't get a reply sent only to the list at once. Thus mailing direct to the person asking is reasonable. Replying also to the list has several values as well. Others will see that they don't need to reply. People looking through mailing list archives will find answers, not only questions. (This is always a good thing to do before asking questions.) Also, the other subscribers on the list learn things from the replies. If it's more of a discussion, and not a direct question, I tent to do "Reply to all" to get the first line right "N N wrote:" instead of "you wrote:", but edit the To: and/or Cc: fields so that only the list gets the mail. >41 Lacplesa Str. Hey, I stayed on Lactplesa Iela when I was teaching Tuxedo in Riga this spring! :) -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From c.attianese@cib.na.cnr.it Tue Nov 5 17:31:11 2002 From: c.attianese@cib.na.cnr.it (Carla Attianese) Date: Tue, 5 Nov 2002 18:31:11 +0100 Subject: [DB-SIG] string assignment Message-ID: <004601c284f1$24c96b80$d005a48c@epicuro> This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C284F9.84493AB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everybody, I'm writing a python script that tries to connect to informix DB. I got = an error in assigning a SQL Create Table statement to a variable. This = is how I did it: CREATE_TABLE =3D """ CREATE TABLE (...... I got an invalid syntax error at the first line. I tried with single = quote, getting the same error.It seems not to accept an assignment of a = string to a variable. I'm using Python 2.1.1 on WIndows XP. Am I doing = something wrong with the syntax? Thank you and best regards Carla ___________________________ Carla Attianese c.attianese@cib.na.cnr.it CNR - Cybernetics Institute Via Campi Flegrei, 34 I-80072 Pozzuoli (Naples), Italy +39818675157 ------=_NextPart_000_0043_01C284F9.84493AB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everybody,
I'm writing a python script that tries = to connect=20 to informix DB. I got an error in assigning a SQL Create Table statement = to a=20 variable. This is how I did it:
 
CREATE_TABLE =3D """
CREATE TABLE (......
 
I got an invalid syntax = error at the=20 first line. I tried with single quote, getting the same error.It seems = not to=20 accept an assignment of a string to a variable. I'm using Python 2.1.1 = on=20 WIndows XP. Am I doing something wrong with the = syntax?
Thank you and best regards
Carla
 
 
___________________________
Carla Attianese
c.attianese@cib.na.cnr.itCNR -=20 Cybernetics Institute
Via Campi Flegrei, 34  I-80072
Pozzuoli = (Naples), Italy
+39818675157
------=_NextPart_000_0043_01C284F9.84493AB0-- From magnus@thinkware.se Tue Nov 5 19:03:11 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 05 Nov 2002 20:03:11 +0100 Subject: [DB-SIG] string assignment In-Reply-To: <004601c284f1$24c96b80$d005a48c@epicuro> Message-ID: <5.1.0.14.0.20021105195826.02b60200@www.thinkware.se> At 18:31 2002-11-05 +0100, Carla Attianese wrote: >Hi everybody, >I'm writing a python script that tries to connect to informix DB. I got an >error in assigning a SQL Create Table statement to a variable. This is how >I did it: > >CREATE_TABLE = """ >CREATE TABLE (...... > >I got an invalid syntax error at the first line. I tried with single >quote, getting the same error.It seems not to accept an assignment of a >string to a variable. I'm using Python 2.1.1 on WIndows XP. Am I doing >something wrong with the syntax? If you get a syntax error it seems you are. If you are getting it on that line, it's probably a bit off topic for this mailing list though... ;) I think you are looking for the problem in the wrong place. Might there be inconsistent whitespace or something like that? A space before CREATE_TABLE ??? Or have you forgotten a closing ), ] or } just before? -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From djc@object-craft.com.au Wed Nov 20 01:25:48 2002 From: djc@object-craft.com.au (Dave Cole) Date: 20 Nov 2002 12:25:48 +1100 Subject: [DB-SIG] Sybase module 0.35 released Message-ID: 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: In this release the module uses callback instead of inline error handling from the Sybase CT library. This has caused quite extensive changes to the threading support inside the low level extension module. One of the nice side effects of using callback error handling is that server errors while executing stored procedures will now be reported correctly. FreeTDS support is much improved in this version. 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.35.tar.gz The module home page is here: http://www.object-craft.com.au/projects/sybase/ CHANGES SINCE 0.35pre3: No problems were reported with the 0.35pre3 release so the changes are minimal. * sybasect extension module now includes a __version__ string. -- http://www.object-craft.com.au From werner.bruhin@free.fr Sat Nov 23 18:43:30 2002 From: werner.bruhin@free.fr (Werner F. Bruhin) Date: Sat, 23 Nov 2002 10:43:30 -0800 Subject: [DB-SIG] (no subject) Message-ID: <3DDFCC52.4070305@free.fr> From jim@joshua.smcvt.edu Tue Nov 26 19:11:31 2002 From: jim@joshua.smcvt.edu (Jim Hefferon) Date: Tue, 26 Nov 2002 14:11:31 -0500 Subject: [DB-SIG] what's wrong an exception-catching class? Message-ID: <200211261911.OAA11392@joshua.smcvt.edu> Hi. I am new to db programming in Python, so forgive me if this is an easy one; I've looked for the answer in groups.google.com, on a few months of this list, and at google in general, but I've not found it. The 2.0 specification doesn't delimit which exceptions each operation may raise. I'm doing a web interface thing and I'd like to be very careful, and in addtion provide as much information about any error as possible. So I thought to make a class dbOp with a method def submit(self): try: self.operation() except PgSQL.DataError, err: raise dbError, self.handleDataError(err) except PgSQL.OperationalError, err: raise dbError, self.handleOperationalError(err) ... etc: every legal exception is handled ... where the handle* routines do things like print a sensible error message, produce the traceback, etc. This way, I can subclass to dbConnect where the operation method makes a connection and creates a cursor. I can also subclass to dbQuery where the operation runs self.cursor.execute(...) (for this one __init__ gets the cursor and the statement when the instantation is made). I can share working code if I've not explained myself enough. Now, the question. This seems to me to be the natural thing to do. But I've not found versions of this code anywhere, nor have I seen this approach mentioned; this includes books on the subject. Is there some tremendous drawback? That is, my try is obvious enough that the fact that I can't find it used makes me think that it must be obvious but wrong-headed. Is it? Thanks, Jim From chris@cogdon.org Tue Nov 26 19:32:19 2002 From: chris@cogdon.org (Chris Cogdon) Date: Tue, 26 Nov 2002 11:32:19 -0800 Subject: [DB-SIG] what's wrong an exception-catching class? In-Reply-To: <200211261911.OAA11392@joshua.smcvt.edu> Message-ID: On Tuesday, Nov 26, 2002, at 11:11 US/Pacific, Jim Hefferon wrote: > Hi. > > I am new to db programming in Python, so forgive me if this is an > easy one; I've looked for the answer in groups.google.com, on > a few months of this list, and at google in general, but I've not > found it. > > The 2.0 specification doesn't delimit which exceptions > each operation may raise. I'm doing a web interface thing and I'd > like to be very careful, and in addtion provide as much information > about any error as possible. > > So I thought to make a class dbOp with a method > > def submit(self): > try: > self.operation() > except PgSQL.DataError, err: > raise dbError, self.handleDataError(err) > except PgSQL.OperationalError, err: > raise dbError, self.handleOperationalError(err) > ... etc: every legal exception is handled ... > > where the handle* routines do things like print a sensible error > message, produce the traceback, etc. This way, I can subclass to > dbConnect where the operation method makes a connection and creates a > cursor. I can also subclass to dbQuery where the operation runs > self.cursor.execute(...) (for this one __init__ gets the cursor > and the statement when the instantation is made). I can share > working code if I've not explained myself enough. > > Now, the question. This seems to me to be the natural thing to > do. But I've not found versions of this code anywhere, nor have > I seen this approach mentioned; this includes books on the subject. > Is there some tremendous drawback? > > That is, my try is obvious enough that the fact that I can't find it > used > makes me think that it must be obvious but wrong-headed. Is it? Generally, it's not 'good form' for a library to catch exceptions. The whole idea of exceptions is for the 'application' to handle exceptions in a way that is appropriate for the application. For example, in an interactive application, it makes sense for DB errors to be printed out in a descriptive way. For another application, say an embedded, headless, remote data-collecting facility, printing out exceptions is absolutely the wrong thing to do. This is why I feel that there is no 'standard library' for catching exceptions, because the 'correct' thing for any particular application varies widely and wildly between applications. -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From magnus@thinkware.se Tue Nov 26 22:17:13 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 26 Nov 2002 23:17:13 +0100 Subject: [DB-SIG] what's wrong an exception-catching class? In-Reply-To: References: <200211261911.OAA11392@joshua.smcvt.edu> Message-ID: <5.1.0.14.0.20021126231253.035e1830@www.thinkware.se> At 11:32 2002-11-26 -0800, Chris Cogdon wrote: >This is why I feel that there is no 'standard library' for catching >exceptions, because the 'correct' thing for any particular application >varies widely and wildly between applications. On the other hand, it could be useful if the raised exceptions followed some kind of standard. After all, it's not the vendor specific code that throws Python exceptions, it's the Python database drivers. If there was a standard for these exceptions, it would be easier to write generic DB-API programs. IIRC, this has been discussed on this list... -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From chris@cogdon.org Tue Nov 26 22:22:51 2002 From: chris@cogdon.org (Chris Cogdon) Date: Tue, 26 Nov 2002 14:22:51 -0800 Subject: [DB-SIG] what's wrong an exception-catching class? In-Reply-To: <5.1.0.14.0.20021126231253.035e1830@www.thinkware.se> Message-ID: <9A2AAA6A-018D-11D7-9579-000393A6D442@cogdon.org> On Tuesday, Nov 26, 2002, at 14:17 US/Pacific, Magnus Lycka wrote: > At 11:32 2002-11-26 -0800, Chris Cogdon wrote: >> This is why I feel that there is no 'standard library' for catching >> exceptions, because the 'correct' thing for any particular >> application varies widely and wildly between applications. > > On the other hand, it could be useful if the raised exceptions > followed some kind of standard. After all, it's not the vendor > specific code that throws Python exceptions, it's the Python > database drivers. If there was a standard for these exceptions, > it would be easier to write generic DB-API programs. IIRC, this > has been discussed on this list... Oh... absolutely agree. And if the database writer needs to add in special information to the exceptions, then she can subclass the standard exceptions. -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From mal@lemburg.com Wed Nov 27 08:27:24 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 27 Nov 2002 09:27:24 +0100 Subject: [DB-SIG] what's wrong an exception-catching class? References: <9A2AAA6A-018D-11D7-9579-000393A6D442@cogdon.org> Message-ID: <3DE481EC.2040506@lemburg.com> Chris Cogdon wrote: > > On Tuesday, Nov 26, 2002, at 14:17 US/Pacific, Magnus Lycka wrote: > >> At 11:32 2002-11-26 -0800, Chris Cogdon wrote: >> >>> This is why I feel that there is no 'standard library' for catching >>> exceptions, because the 'correct' thing for any particular >>> application varies widely and wildly between applications. >> >> >> On the other hand, it could be useful if the raised exceptions >> followed some kind of standard. After all, it's not the vendor >> specific code that throws Python exceptions, it's the Python >> database drivers. If there was a standard for these exceptions, >> it would be easier to write generic DB-API programs. IIRC, this >> has been discussed on this list... > > > Oh... absolutely agree. And if the database writer needs to add in > special information to the exceptions, then she can subclass the > standard exceptions. I don't understand... we *do* have a standard exception hierarchy for DB-API related errors: This is the exception inheritance layout: StandardError |__Warning |__Error |__InterfaceError |__DatabaseError |__DataError |__OperationalError |__IntegrityError |__InternalError |__ProgrammingError |__NotSupportedError If you write programs like so: # Change this line if you port to another DB-API wrapper: import myDBwrapper as dbapi ... try: cursor.execute(...) except dbapi.Error, why: print 'Ooops: %s' % why you pretty much get what you want. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From darcy@druid.net Wed Nov 27 13:03:03 2002 From: darcy@druid.net (D'Arcy J.M. Cain) Date: Wed, 27 Nov 2002 08:03:03 -0500 Subject: [DB-SIG] PyGreSQL pgsource object In-Reply-To: <200210281234.g9SCY1M22982@grad.sccs.chukyo-u.ac.jp> References: <200210281234.g9SCY1M22982@grad.sccs.chukyo-u.ac.jp> Message-ID: <20021127130303.D50651A7D@druid.net> On October 28, 2002 07:34 am, Tamito KAJIYAMA wrote: > I found that the pg module in PyGreSQL (version 3.x) contains an > extension object named pgsource. It seems useful, but it is not > mentioned in the documentation at all. Does this means that the > pgsource object should not be used in PyGreSQL applications? The C module that is imported by pg (Classic interface) and pgdb(DB-API interface) gets imported into both high level modules but not everything is used ini both. That object in particular is used by the pgdb module and is ignored in the pg module. In fact, I have recently broached the subject in the PyGreSQL mailing list of combining that object with the pgobject as a start on rationalizing the dual nature of PyGreSQL. Perhaps one day there will only be one module and the classic interface will simply be extensions to the DB-API interface. See http://mail.vex.net:99/pipermail/pygresql/2002-November/000564.html for the message referred to above. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From darcy@druid.net Wed Nov 27 13:08:39 2002 From: darcy@druid.net (D'Arcy J.M. Cain) Date: Wed, 27 Nov 2002 08:08:39 -0500 Subject: [DB-SIG] PyGreSQL pgsource object In-Reply-To: <200210281555.g9SFt2123275@grad.sccs.chukyo-u.ac.jp> References: <20021028135044.GA1392@HAERING> <200210281555.g9SFt2123275@grad.sccs.chukyo-u.ac.jp> Message-ID: <20021127130839.C19BD1A7D@druid.net> On October 28, 2002 10:55 am, Tamito KAJIYAMA wrote: > The pgsource object has a set of method names that well > correspond with the PostgreSQL interface in PHP. So, I thought > the pgsource object would be useful when, say, porting database > applications from PHP to Python. Perhaps that's because PHP uses the DB-API interface. If that is the case then you may find that importing pgdb in PyGreSQL rather than pg is what you want. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From magnus@thinkware.se Wed Nov 27 15:32:15 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Wed, 27 Nov 2002 16:32:15 +0100 Subject: [DB-SIG] what's wrong an exception-catching class? In-Reply-To: <3DE481EC.2040506@lemburg.com> References: <9A2AAA6A-018D-11D7-9579-000393A6D442@cogdon.org> Message-ID: <5.1.0.14.0.20021127162924.035dee80@www.thinkware.se> At 09:27 2002-11-27 +0100, M.-A. Lemburg wrote: >I don't understand... we *do* have a standard exception hierarchy >for DB-API related errors: Silly me! :( Can anyone imagine what my fingers really meant to type? I was obviously confused by something... I wonder what... -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From Michael_Scharf@gmx.de Wed Nov 27 16:35:39 2002 From: Michael_Scharf@gmx.de (Michael Scharf) Date: Wed, 27 Nov 2002 17:35:39 +0100 Subject: [DB-SIG] Uittests for Python Database API Specification 2.0 Message-ID: <3DE4F45B.1030701@gmx.de> Hi, are there any unit tests for the "Python Database API Specification 2.0". I have seen some kind of tests in mxODBC, but I wonder if there is a set of unit tests that can be used to check the conformance to the PDAPI2.0? It would also be cool to have tests that tell you which features a particular PDAPI2.0 database implements. That could be helpful for deciding which database to use. It would also help when one wants to switch to another implementation. Another nice thing would be to have a set of performance tests based on the PDAPI2.0. That could be very helpful when to compare different implementations. There are so many databases and it's really hard to decide which one to use (given some performance constraints)... What's also interesting sometimes it the disk space (% of wasted disk space given a data set) and (maximum) memory usage of a database. Finally, installation size is important sometimes. It would be really cool to have a database of information like that for as many PDAPI2.0 implementations as possible... Michael From Michael_Scharf@gmx.de Wed Nov 27 16:44:08 2002 From: Michael_Scharf@gmx.de (Michael Scharf) Date: Wed, 27 Nov 2002 17:44:08 +0100 Subject: [DB-SIG] Anydbm like interface for PyDbAPI2.0 databases? Message-ID: <3DE4F658.8090103@gmx.de> Hi, is there an Anydbm (http://python.org/doc/current/lib/module-anydbm.html) adaptors for PyDbAPI2.0 database? Michael From gerhard.haering@opus-gmbh.net Wed Nov 27 16:50:59 2002 From: gerhard.haering@opus-gmbh.net (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Wed, 27 Nov 2002 17:50:59 +0100 Subject: [DB-SIG] Anydbm like interface for PyDbAPI2.0 databases? In-Reply-To: <3DE4F658.8090103@gmx.de> References: <3DE4F658.8090103@gmx.de> Message-ID: <20021127165059.GA1412@HAERING2> * Michael Scharf [2002-11-27 17:44 +0100]: > Hi, > > is there an Anydbm > (http://python.org/doc/current/lib/module-anydbm.html) > adaptors for PyDbAPI2.0 database? That wouldn't make much sense IMO. If you only want the primitive DBM interface, why use a relational database as a backend? -- Gerhard Häring OPUS GmbH München Tel.: +49 89 - 889 49 7 - 32 http://www.opus-gmbh.net/ From gerhard.haering@opus-gmbh.net Wed Nov 27 16:59:37 2002 From: gerhard.haering@opus-gmbh.net (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Wed, 27 Nov 2002 17:59:37 +0100 Subject: [DB-SIG] Uittests for Python Database API Specification 2.0 In-Reply-To: <3DE4F45B.1030701@gmx.de> References: <3DE4F45B.1030701@gmx.de> Message-ID: <20021127165937.GB1412@HAERING2> * Michael Scharf [2002-11-27 17:35 +0100]: > Hi, > > are there any unit tests for the "Python Database API Specification 2.0". Federico has once start working on some. I believe I have seen them once somewhere at http://initd.org/, but can't find it currently. > I have seen some kind of tests in mxODBC, but I wonder if there is a set > of unit tests that can be used to check the conformance to the PDAPI2.0? AFAIK nothing finished, currently. > [...] Another nice thing would be to have a set of performance tests based on > the PDAPI2.0. That could be very helpful when to compare different > implementations. That'd mostly be useful for comparing different DB-API modules for the same database, as the DB-API wrappers have overhead, too. Sometimes quite considerable overhead. But for many applications, this is not a problem at all. > There are so many databases and it's really hard to > decide which one to use (given some performance constraints)... > > What's also interesting sometimes it the disk space (% of wasted disk > space given a data set) and (maximum) memory usage of a database. > > Finally, installation size is important sometimes. These are all characteristica of the RDBMS used. And unfortunately, it's hard to get such data, because it fall in the benchmark category. And the commercial RDMBS vendors are such losers that they all forbid publishing benchmark results in their license agreements. Even fairly comparing open-source implementations is difficult enough, as can be seen by the numerous flamings between the PostgreSQL and the MySQL camp, for example. -- Gerhard Häring OPUS GmbH München Tel.: +49 89 - 889 49 7 - 32 http://www.opus-gmbh.net/ From Michael_Scharf@gmx.de Wed Nov 27 17:20:12 2002 From: Michael_Scharf@gmx.de (Michael Scharf) Date: Wed, 27 Nov 2002 18:20:12 +0100 Subject: [DB-SIG] Anydbm like interface for PyDbAPI2.0 databases? References: <3DE4F658.8090103@gmx.de> <20021127165059.GA1412@HAERING2> Message-ID: <3DE4FECC.6080705@gmx.de> Gerhard Häring wrote: > That wouldn't make much sense IMO. If you only want the primitive DBM > interface, why use a relational database as a backend? DBM is essentially a simplified (dict like) interface to a table with two columns. If I have a RDB already installed, why using another db for dict like stuff? So, why not using a dict like interface for 2 column tables? Michael From mal@lemburg.com Wed Nov 27 17:31:05 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 27 Nov 2002 18:31:05 +0100 Subject: [DB-SIG] Anydbm like interface for PyDbAPI2.0 databases? References: <3DE4F658.8090103@gmx.de> <20021127165059.GA1412@HAERING2> <3DE4FECC.6080705@gmx.de> Message-ID: <3DE50159.6020207@lemburg.com> Michael Scharf wrote: > Gerhard H=E4ring wrote: > > That wouldn't make much sense IMO. If you only want the primitive DB= M > > interface, why use a relational database as a backend? >=20 > DBM is essentially a simplified (dict like) interface to a > table with two columns. If I have a RDB already installed, > why using another db for dict like stuff? So, why not using a > dict like interface for 2 column tables? Should be easy to write and probably works as nice excerise to get used to the DB API. Have fun, --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Michael_Scharf@gmx.de Wed Nov 27 17:39:56 2002 From: Michael_Scharf@gmx.de (Michael Scharf) Date: Wed, 27 Nov 2002 18:39:56 +0100 Subject: [DB-SIG] Uittests for Python Database API Specification 2.0 References: <3DE4F45B.1030701@gmx.de> <20021127165937.GB1412@HAERING2> Message-ID: <3DE5036C.3030309@gmx.de> Gerhard Häring wrote: > That'd mostly be useful for comparing different DB-API > modules for the same database, as the DB-API wrappers have > overhead, too. Sometimes quite considerable overhead. But > for many applications, this is not a problem at all. Well that's good. It would tests DB-engine + DB-API. That's what you get as user anyway, and you somehow don't care where exactly the performance bottleneck is. If there are different DB-API's to choose, I think the tradeoff might be speed for functionality. With a set of tests you can see what's important for your application (thread safety, speed, salability,...) >>What's also interesting sometimes it the disk space (% of wasted disk >>space given a data set) and (maximum) memory usage of a database. >>Finally, installation size is important sometimes. > > These are all characteristica of the RDBMS used. Indeed, but what matters most of the time is the TOTAL performance. If a high speed DB-engine appears very slow because of a bad DB-API implementation, testing the DB-engine itself is not very helpful, if you want to use it from python (and you depend on the DB-API). > And unfortunately, it's hard to get such data, because it > fall in the benchmark category. And the commercial RDMBS > vendors are such losers that they all forbid publishing > benchmark results in their license agreements. OH, I didn't know that. Therefore it's even more important to have such tests, so everybody can run his own tests and compare ;-) > Even fairly comparing open-source implementations is > difficult enough, as can be seen by the numerous flamings > between the PostgreSQL and the MySQL camp, for example. OK, each implementation could contribute tests that make their DB look good. If the tests explain what they do, a user can decide if this is what he needs. Michael From mal@lemburg.com Wed Nov 27 17:39:43 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 27 Nov 2002 18:39:43 +0100 Subject: [DB-SIG] Unittests for Python Database API Specification 2.0 References: <3DE4F45B.1030701@gmx.de> Message-ID: <3DE5035F.6020605@lemburg.com> Michael Scharf wrote: > Hi, > > are there any unit tests for the "Python Database API Specification 2.0". > I have seen some kind of tests in mxODBC, but I wonder if there is a set > of unit tests that can be used to check the conformance to the PDAPI2.0? Indeed. mxODBC has a test script which is used to test the interface, but also to check the capabilities of the ODBC drivers and the database backend. > It would also be cool to have tests that tell you which features a > particular PDAPI2.0 database implements. That could be helpful for > deciding which database to use. It would also help when one wants to > switch to another implementation. Reading the documentation usually helps more :-) > Another nice thing would be to have a set of performance tests based > on the PDAPI2.0. That could be very helpful when to compare different > implementations. There are so many databases and it's really hard to > decide which one to use (given some performance constraints)... I don't think that the interfaces cost that performance. It's the database sitting behind the interface that's causing differing performance... choosing a database is much like choosing a car: you have cheap ones, expensive ones, fast and slow ones, heavy weights and Smarts, etc. Simple tests like the one used in mxODBC don't give you enough information to help you decide. You should also not forget that database administration is an important factor: running DB2 or Oracle is a full-time job for quite a few IT-people. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From chris@cogdon.org Wed Nov 27 18:04:25 2002 From: chris@cogdon.org (Chris Cogdon) Date: Wed, 27 Nov 2002 10:04:25 -0800 Subject: [DB-SIG] Anydbm like interface for PyDbAPI2.0 databases? In-Reply-To: <20021127165059.GA1412@HAERING2> Message-ID: On Wednesday, Nov 27, 2002, at 08:50 US/Pacific, Gerhard H=E4ring wrote: > * Michael Scharf [2002-11-27 17:44 +0100]: >> Hi, >> >> is there an Anydbm >> (http://python.org/doc/current/lib/module-anydbm.html) >> adaptors for PyDbAPI2.0 database? > > That wouldn't make much sense IMO. If you only want the primitive DBM > interface, why use a relational database as a backend? Because, you might already have code that expects a dictionary-like=20 interface, and you want to run this code over a existing or future=20 relational database set. And... even if you're writing new code, if you're writing a library=20 that doesn't need anything more than a dictionary-like interface, why=20 write for a relational? t's all about code reuse! :) --=20 ("`-/")_.-'"``-._ Ch'marr, a.k.a. . . `; -._ )-;-,_`) Chris Cogdon (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' FC1.3:=20 FFH3cmA+>++C++D++H++M++P++R++T+++WZ++Sm++ ((,.-' ((,/ fL RLCT acl+++d++e+f+++h++i++++jp-sm++ From jim@joshua.smcvt.edu Wed Nov 27 20:26:30 2002 From: jim@joshua.smcvt.edu (Jim Hefferon) Date: Wed, 27 Nov 2002 15:26:30 -0500 Subject: [DB-SIG] what's wrong with an exception-catching class? In-Reply-To: <3DE481EC.2040506@lemburg.com> (mal@lemburg.com) References: <9A2AAA6A-018D-11D7-9579-000393A6D442@cogdon.org> <3DE481EC.2040506@lemburg.com> Message-ID: <200211272026.PAA14124@joshua.smcvt.edu> > Chris Cogdon wrote: >>> This is why I feel that there is no 'standard library' for catching >>> exceptions, because the 'correct' thing for any particular >>> application varies widely and wildly between applications. But then how do I avoid having the outer level in my programs filled with many 30-line try: .. except DataError .. except OperationalError ... sections? I want to refactor, to write that once and have it done right, so I thought to do a dbOp object that encapsulates the behavior. But I can't see why I've not found discussion of that encapsulation. > Magnus Lycka wrote: If you write programs like so: # Change this line if you port to another DB-API wrapper: import myDBwrapper as dbapi ... try: cursor.execute(...) except dbapi.Error, why: print 'Ooops: %s' % why you pretty much get what you want. So is this DB-API wrapper what I am writing? Because that section of code is what I now have at my outer layer. Has this been discussed here previously, or are there examples of such wrappers in archives, and I have just not been able to find them? Thanks for the help, Jim From thierry.michel@nekhem.com Thu Nov 28 00:54:55 2002 From: thierry.michel@nekhem.com (Thierry MICHEL) Date: 28 Nov 2002 01:54:55 +0100 Subject: [DB-SIG] Uittests for Python Database API Specification 2.0 In-Reply-To: <20021127165937.GB1412@HAERING2> References: <3DE4F45B.1030701@gmx.de> <20021127165937.GB1412@HAERING2> Message-ID: <1038444894.962.13.camel@localhost> On Wed, 2002-11-27 at 17:59, Gerhard H=E4ring wrote: > * Michael Scharf [2002-11-27 17:35 +0100]: > > Hi, > >=20 > > are there any unit tests for the "Python Database API Specification 2.0= ". >=20 > Federico has once start working on some. I believe I have seen them once > somewhere at http://initd.org/, but can't find it currently. I'm helping him to write entire test suite for DBAPI1.0 compliance. Right now, I have personaly slow down the project, because I'm very busy w/ my work. But, I think to continue this development soon. >=20 > > I have seen some kind of tests in mxODBC, but I wonder if there is a se= t > > of unit tests that can be used to check the conformance to the PDAPI2.0= ? >=20 > AFAIK nothing finished, currently. >=20 > > [...] Another nice thing would be to have a set of performance tests ba= sed on > > the PDAPI2.0. That could be very helpful when to compare different > > implementations. >=20 > That'd mostly be useful for comparing different DB-API modules for the sa= me > database, as the DB-API wrappers have overhead, too. Sometimes quite > considerable overhead. But for many applications, this is not a problem a= t all. >=20 > > There are so many databases and it's really hard to > > decide which one to use (given some performance constraints)... > >=20 > > What's also interesting sometimes it the disk space (% of wasted disk > > space given a data set) and (maximum) memory usage of a database. > >=20 > > Finally, installation size is important sometimes. >=20 > These are all characteristica of the RDBMS used. And unfortunately, it's = hard > to get such data, because it fall in the benchmark category. And the comm= ercial > RDMBS vendors are such losers that they all forbid publishing benchmark r= esults > in their license agreements. >=20 > Even fairly comparing open-source implementations is difficult enough, as= can > be seen by the numerous flamings between the PostgreSQL and the MySQL cam= p, for > example. Thanks to be patient, Best regards, From alust@UralskyGSM.com Fri Nov 29 09:57:48 2002 From: alust@UralskyGSM.com (Alexei Ustyuzhaninov) Date: Fri, 29 Nov 2002 14:57:48 +0500 Subject: [DB-SIG] Returning floats in DCOracle2 Message-ID: <3DE73A1C.5020901@UralskyGSM.com> Hi! I have ran into a silly problem with DCOracle2. It returns wrong float numbers from SELECT statement. bash-2.04$ cat test.py import DCOracle2 db = DCOracle2.connect("x/y@z") c = db.cursor() c.execute("SELECT 0.5 FROM DUAL") print c.fetchone() bash-2.04$ python test.py [3.6097722056218853] Unfortunately 0.5 is somewhat different from 3.6097722056218853. The environment is: HP-UX 11.11 python 2.2.2 DCOracle2 1.2 Could somebody give me a tip on the problem please? -- Best regards, Alexei Ustyuzhaninov From jno@glasnet.ru Fri Nov 29 13:56:14 2002 From: jno@glasnet.ru (jno) Date: 29 Nov 2002 16:56:14 +0300 Subject: [DB-SIG] Returning floats in DCOracle2 In-Reply-To: <3DE73A1C.5020901@UralskyGSM.com> References: <3DE73A1C.5020901@UralskyGSM.com> Message-ID: <1038578174.5061.31.camel@jno.glas.net> --=-5X0nhpnnsi12xADBzbrr Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable could not reproduce: [jno@hypnos jno]$ python =20 Python 2.1.3 (#2, Jul 24 2002, 11:13:04) [C] on hp-uxB Type "copyright", "credits" or "license" for more information. >>> import DCOracle >>> d =3D DCOracle.Connect('xxx/xxx@xxx') >>> c =3D d.cursor() >>> c.execute('select 0.5 from dual') >>> r=3Dc.fetchall() >>> c.close() >>> print r [(0.5,)] >>>=20 [jno@hypnos jno]$ uname -a HP-UX hypnos B.11.00 U 9000/800 654339382 unlimited-user license [jno@hypnos jno]$=20 well, it is NOT DCO2, Py 2.2.2 and HP-UX 11.11 ;-) -jno =F7 =F0=D4=CE, 29.11.2002, =D7 12:57, Alexei Ustyuzhaninov =CE=C1=D0=C9=D3= =C1=CC: > Hi! >=20 > I have ran into a silly problem with DCOracle2. It returns wrong float=20 > numbers from SELECT statement. >=20 > bash-2.04$ cat test.py > import DCOracle2 > db =3D DCOracle2.connect("x/y@z") > c =3D db.cursor() > c.execute("SELECT 0.5 FROM DUAL") > print c.fetchone() >=20 > bash-2.04$ python test.py > [3.6097722056218853] >=20 > Unfortunately 0.5 is somewhat different from 3.6097722056218853. > The environment is: > HP-UX 11.11 > python 2.2.2 > DCOracle2 1.2 >=20 > Could somebody give me a tip on the problem please? >=20 > --=20 > Best regards, > Alexei Ustyuzhaninov >=20 >=20 > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig --=-5X0nhpnnsi12xADBzbrr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA953H+ev10erQBAdYRAnPdAKDH3O5WYzkNTIcrsLTjekUvypv5hgCeKo8H YHjuDVDtapQzliEJd0ZByWE= =gLE8 -----END PGP SIGNATURE----- --=-5X0nhpnnsi12xADBzbrr-- From ramrom@earthling.net Sat Nov 30 11:43:17 2002 From: ramrom@earthling.net (Bob Gailer) Date: Sat, 30 Nov 2002 04:43:17 -0700 Subject: [DB-SIG] Returning floats in DCOracle2 In-Reply-To: <3DE73A1C.5020901@UralskyGSM.com> Message-ID: <5.2.0.9.0.20021130044310.01a1ccc0@66.28.54.253> At 02:57 PM 11/29/2002 +0500, you wrote: >I have ran into a silly problem with DCOracle2. It returns wrong float >numbers from SELECT statement. > >bash-2.04$ cat test.py >import DCOracle2 >db = DCOracle2.connect("x/y@z") >c = db.cursor() >c.execute("SELECT 0.5 FROM DUAL") >print c.fetchone() > >bash-2.04$ python test.py >[3.6097722056218853] Interesting. Using cxOracle this works fine. Bob Gailer mailto:ramrom@earthling.net 303 442 2625