From ib@procom.de Mon Feb 3 17:48:45 1997 From: ib@procom.de (Markus Indenbirken) Date: Mon, 3 Feb 97 17:48:45 MEZ Subject: [PYTHON DB-SIG] oracledb examples Message-ID: <9702031640.AA16073@mser.procom.de > Hi folks, a few days ago I downloaded the oracledb module. Before I have been using Tom Culliton's Oracle module successfully, but I was looking for greater speed. I'm looking for sample code on inserting multiple rows at a time, which I understand is possible using the oracledb module. Any hints ??? Thanks, Markus -- Markus Indenbirken E-Mail: ib@procom.de P r o C o m GmbH Phone : +49/241/51804-46 Aachen, Germany Fax : +49/241/51804-30 _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim.fulton@digicool.com Mon Feb 3 19:51:24 1997 From: jim.fulton@digicool.com (Jim Fulton) Date: Mon, 03 Feb 1997 14:51:24 -0500 Subject: [PYTHON DB-SIG] oracledb examples References: <9702031640.AA16073@mser.procom.de > Message-ID: <32F641BC.3A04@digicool.com> Markus Indenbirken wrote: > > Hi folks, > > a few days ago I downloaded the oracledb module. Before I have been using > Tom Culliton's Oracle module successfully, but I was looking for greater > speed. > > I'm looking for sample code on inserting multiple rows at a time, which I > understand is possible using the oracledb module. The oracldb is supposed to cache prepared sql statements, like this: import oracledb db=oracldb.oracledb("spam/spamsecret@spamhost") c=db.cursor() insert="insert into spam values(:1, :2)" for tup in some_data: c.execute(insert,tup) db.commit() where tup is a tuple with two values. Theoretically, the cursor detects that the same string is passed to each execute call and doesn't have to prepare the statement on each call. Unfortunately, this has not yet been implemented. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.python.org/ ## _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From aaron_watters@msn.com Tue Feb 4 03:03:29 1997 From: aaron_watters@msn.com (aaron watters) Date: Tue, 4 Feb 97 03:03:29 UT Subject: [PYTHON DB-SIG] oracledb examples Message-ID: When I used the oracledb I never got multirow inserts to work. Maybe I was doing something wrong, though. Single row inserts seemed pretty fast, at least for the sort of batch processing I was doing. Supposedly if the command string doesn't change it need not be reparsed and reprepared, but I don't know if this possibility is actually implemented. - Aaron Watters ---------- From: owner-db-sig@python.org on behalf of Markus Indenbirken I'm looking for sample code on inserting multiple rows at a time, which I understand is possible using the oracledb module. Markus -- Markus Indenbirken E-Mail: ib@procom.de _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From orjan@spinne.ip.lu Wed Feb 5 17:47:15 1997 From: orjan@spinne.ip.lu (Orjan Reinholdsen) Date: Wed, 5 Feb 1997 17:47:15 +0000 Subject: [PYTHON DB-SIG] Python vs Perl DB API Message-ID: Hello! Lately, I'v left Perl behind and I'm now using Python (and 'oracledb') to interface our Oracle DB. Generally this works great and I really adore the Python syntax compared to Perl, but now I'v run into some questions regarding speed: I'v timed the execution of a Perl script and a Python script doing the same thing, with the result that the Perl script is roughly 3 times faster that the Python script. I should note that the DB operations in the scripts involves a select and the formating of roughly 2500 lines of text output (mainly using 'print'). So the question arise: Why is the Python script significantly slower than the Perl script? Is it because of the "speed" of 'oracledb' and/or the Python DB API, or is it because Python is generically slower that Perl? Any suggestions for speed improvement?? Happy for ANY answer. Regards, Orjan Reinholdsen ================================================================================ Orjan Reinholdsen Infopartners SA Voice: +352 29 57 59 33 02 Fax: +352 29 57 59 39 00 e-mail: orjan@ip.lu ================================================================================ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From mlorton@microsoft.com Wed Feb 5 19:07:24 1997 From: mlorton@microsoft.com (Michael Lorton) Date: Wed, 5 Feb 1997 11:07:24 -0800 Subject: [PYTHON DB-SIG] Python vs Perl DB API Message-ID: >-----Original Message----- >From: Orjan Reinholdsen [SMTP:orjan@spinne.ip.lu] > >I'v timed the execution of a Perl script and a Python script >doing the same thing, with the result that the Perl script is >roughly 3 times faster that the Python script. I should note that the >DB operations in the scripts involves a select and the formating >of roughly 2500 lines of text output (mainly using 'print'). > >So the question arise: Why is the Python script significantly slower >than the Perl script? Is it because of the "speed" of 'oracledb' >and/or the Python DB API, or is it because Python is generically >slower that Perl? Any suggestions for speed improvement?? > >1. The Oracle interface is not optimized for speed of execution so much as >speed of implementation :-). In particular, it re-prepares and re-binds a >query whenever it is reused. I would call the author of it all sort of >filthy names, except I wrote the code myself. > >2. Formatting of output is (or should be) Perl's particular metier. > >BTW, where is ".lu"? Lithuania? > >M. > _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Wed Feb 5 19:45:57 1997 From: gstein@microsoft.com (Greg Stein) Date: Wed, 5 Feb 1997 11:45:57 -0800 Subject: [PYTHON DB-SIG] oracledb examples Message-ID: >---------- >From: Jim Fulton[SMTP:jim.fulton@digicool.com] >Sent: Monday, February 03, 1997 11:51 AM >To: Markus Indenbirken >Cc: Python DB-SIG >Subject: Re: [PYTHON DB-SIG] oracledb examples > >Markus Indenbirken wrote: >> >> Hi folks, >> >> a few days ago I downloaded the oracledb module. Before I have been using >> Tom Culliton's Oracle module successfully, but I was looking for greater >> speed. >> >> I'm looking for sample code on inserting multiple rows at a time, which I >> understand is possible using the oracledb module. > >The oracldb is supposed to cache prepared sql statements, like this: > > import oracledb > db=oracldb.oracledb("spam/spamsecret@spamhost") > c=db.cursor() > insert="insert into spam values(:1, :2)" > for tup in some_data: c.execute(insert,tup) > db.commit() > >where tup is a tuple with two values. Theoretically, >the cursor detects that the same string is passed to >each execute call and doesn't have to prepare the statement >on each call. Unfortunately, this has not yet been >implemented. This is not implemented yet, either, but the following code is "legal" : import oracledb db=oracledb.oracledb("spam/spamsecret@spamhost") c=db.cursor() c.execute("insert into spam values (:1, :2)", some_data) db.commit() e.g. a sequence of sequences is valid for inserts and specifies an array insert. -g -- Greg Stein, Microsoft Corporation execfile("disclaimer.py") _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From tismer@tismer.com Wed Feb 5 21:02:35 1997 From: tismer@tismer.com (Christian Tismer) Date: Wed, 05 Feb 1997 22:02:35 +0100 Subject: [PYTHON DB-SIG] Python vs Perl DB API References: Message-ID: <32F8F56B.58F2@tismer.com> > Lately, I'v left Perl behind and I'm now using Python (and Goooood > 'oracledb') to interface our Oracle DB. Generally this works great > and I really adore the Python syntax compared to Perl, but now I'v > run into some questions regarding speed: > > I'v timed the execution of a Perl script and a Python script > doing the same thing, with the result that the Perl script is > roughly 3 times faster that the Python script. I should note that the > DB operations in the scripts involves a select and the formating > of roughly 2500 lines of text output (mainly using 'print'). I don't think that it is in the oracledb module. Python tends to be about 2-3 times slower than Persuade Everybody Really Leaveit because there are lots of possible optimizations in Python which will come in one or two versions. It also depends very much on what you do with Python. It is generally not efficient to do few things in small inner loops. > So the question arise: Why is the Python script significantly slower > than the Perl script? Is it because of the "speed" of 'oracledb' > and/or the Python DB API, or is it because Python is generically > slower that Perl? Any suggestions for speed improvement?? It depends how you have done it. The printing stuff can be extremely efficient, if you assemble larger parts, and do not glue pieces together but use the % operator. You might show me the code, and I will see where time is wasted. Python also has a profiler, which might point you to the few lines which make up 90% of the time. > Happy for ANY answer. welcome - chris _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From aaron_watters@msn.com Wed Feb 5 23:27:22 1997 From: aaron_watters@msn.com (aaron watters) Date: Wed, 5 Feb 97 23:27:22 UT Subject: [PYTHON DB-SIG] Python vs Perl DB API Message-ID: Without the code it's hard to say, but I'd assume there may be some room for improvement in your code, as I haven't seen it :). One thing you should do right away is, if you are doing everything at a global level, try just enclosing the whole thing in a function. This can get a 2x speedup when lots of variable references are made -- and it's even faster if you forget to execute the function! There are lots of ways to format text poorly in Python. At the risk of chastisement ;) I'd suggest that some sections (Playing and Generating HTML) which I wrote in Internet Programming with Python (book) describe text formatting in detail - although blinding speed isn't always the focus. Maybe try formatting the data in larger chunks (using s % tuple and string.joinfields etc) and writing directly to sys.stdout. In my oracle grub days I used to load 100000 tuples (lst=curs.fetchmany(100000)) at once, l = map(fmter, lst) mapping a formatter function across them and slam them out to a file using sys.stdout.write(string.joinfields(l, "\n")). I thought this screamed. In general I don't think Python 1.4 properly used is significantly slower than Perl, but in the special case of simple text formatting Perl probably is faster -- after all that's what it was designed to do originally. - Aaron Watters ---------- From: owner-db-sig@python.org on behalf of Orjan Reinholdsen Sent: Wednesday, February 05, 1997 12:47 PM To: db-sig@python.org Subject: [PYTHON DB-SIG] Python vs Perl DB API Hello! Lately, I'v left Perl behind and I'm now using Python (and 'oracledb') to interface our Oracle DB. Generally this works great and I really adore the Python syntax compared to Perl, but now I'v run into some questions regarding speed: I'v timed the execution of a Perl script and a Python script doing the same thing, with the result that the Perl script is roughly 3 times faster that the Python script. I should note that the DB operations in the scripts involves a select and the formating of roughly 2500 lines of text output (mainly using 'print'). So the question arise: Why is the Python script significantly slower than the Perl script? Is it because of the "speed" of 'oracledb' and/or the Python DB API, or is it because Python is generically slower that Perl? Any suggestions for speed improvement?? Happy for ANY answer. Regards, Orjan Reinholdsen ============================================================================== == Orjan Reinholdsen Infopartners SA Voice: +352 29 57 59 33 02 Fax: +352 29 57 59 39 00 e-mail: orjan@ip.lu ============================================================================== == _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From bbum@precipice.com Wed Feb 12 20:25:28 1997 From: bbum@precipice.com (Bill Bumgarner) Date: Wed, 12 Feb 97 15:25:28 -0500 Subject: [PYTHON DB-SIG] dbi conformant sybase module Message-ID: <199702122025.PAA01245@lux.precipice.com> It was asked before-- and spawned a nice conversation, from the look of the message archive. But the result was not a dbi conformant sybase module... so, i'll ask again: Is anyone working on a python DBI conformant sybase module [Ted?]? If so, how much progress has been made and where can I get a hold of the latest source so that I can potentially contributed? Along similar lines; Sybase supports a bulk loading interface-- it is very convenient when loading a massive quantity of data of known conformance all at once... anyone added support for the bulk loading (bcp_) interface to the sybase module? thanks, b.bum _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From pgodman@vgi.com Wed Feb 12 20:57:22 1997 From: pgodman@vgi.com (Peter Godman) Date: Wed, 12 Feb 1997 15:57:22 -0500 (EST) Subject: [PYTHON DB-SIG] dbi conformant sybase module In-Reply-To: <199702122025.PAA01245@lux.precipice.com> Message-ID: On Wed, 12 Feb 1997, Bill Bumgarner wrote: > > It was asked before-- and spawned a nice conversation, from the look of the > message archive. But the result was not a dbi conformant sybase module... > so, i'll ask again: > > Is anyone working on a python DBI conformant sybase module [Ted?]? If so, > how much progress has been made and where can I get a hold of the latest > source so that I can potentially contributed? > Hi- I've just started work on a DBI conformant ct-lib (as opposed to db-lib) module. A db-lib but non-DBI module already exists, thanks to Ted. I'm working on the ct-lib version because I would like to use linux with Sybase, and sybase only seems to provide ct-lib for linux (in aout format, yecchh!). > Along similar lines; Sybase supports a bulk loading interface-- it is very > convenient when loading a massive quantity of data of known conformance all > at once... anyone added support for the bulk loading (bcp_) interface to the > sybase module? > I intend to support bulk loading. Any help, advice, collaboration or anything else people would like to contribute will appreciated. > thanks, > b.bum > Thanks, Peter Godman _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From ted_horst@il.us.swissbank.com Wed Feb 12 21:36:51 1997 From: ted_horst@il.us.swissbank.com (Ted Horst) Date: Wed, 12 Feb 97 15:36:51 -0600 Subject: [PYTHON DB-SIG] Re: python sybase module References: <199702122013.PAA01232@lux.precipice.com> Message-ID: <9702122137.AA01944@ch1d162nwk> I got as far as noting the changes that would have to be made ;-) then I promptly ran out of free time. Making the module would be pretty straight forward, but I was a little worried about backward compatibility with some of my own code. I also was interested in using the ExtensionClass, but I was not sure how this would affect people. I am still interested in doing this, but it is not on my immediate schedule. Ted Begin forwarded message: Content-Type: text/plain From: Bill Bumgarner Date: Wed, 12 Feb 97 15:13:40 -0500 To: ted_horst@il.us.swissbank.com Subject: python sybase module Ted, Have you worked on the standard db interface for python with sybase? thanks, b.bum _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From ib@procom.de Mon Feb 17 16:41:36 1997 From: ib@procom.de (Markus Indenbirken) Date: Mon, 17 Feb 97 16:41:36 MEZ Subject: [PYTHON DB-SIG] Postgres interface Message-ID: <9702171530.AA05376@mser.procom.de > Hi there, I remember reading about an API compliant Postgres95 interface for Python, I think it was mentioned in the API Documentation. However, I have not been able to find it anywhere around. Is it available, usable, still being worked upon, or should I have a try at it myself ??? Greetings, Markus -- Markus Indenbirken E-Mail: ib@procom.de P r o C o m GmbH Phone : +49/241/51804-46 Aachen, Germany Fax : +49/241/51804-30 _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lohrum@inf.fu-berlin.de Mon Feb 17 17:40:00 1997 From: lohrum@inf.fu-berlin.de (Stefan Lohrum) Date: Mon, 17 Feb 97 17:40 MET Subject: [PYTHON DB-SIG] Postgres interface Message-ID: Hi Markus, ib> I remember reading about an API compliant Postgres95 interface for ib> Python, I think it was mentioned in the API Documentation. ib> ib> However, I have not been able to find it anywhere around. ib> >ib Is it available, usable, still being worked upon, or should I have a try at >ib it myself ??? Have a look at: http://www.cwi.nl/www.python.org/ftp/python/contrib/Database/PyGres95-1.0b.tar.gz I tried it together with Python Vers.1.2 and Postgres95 Vers.1.09 and it worked fine. Stefan Lohrum _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Mon Feb 17 18:59:48 1997 From: gstein@microsoft.com (Greg Stein) Date: Mon, 17 Feb 1997 10:59:48 -0800 Subject: [PYTHON DB-SIG] dbi conformant sybase module Message-ID: The DBAPI supports array inserts, but doesn't have any methods defined for bulk loading (e.g. from a file). I would generally tend to say that you'd want to just add a method as needed and it would be a "Sybase-specific" extension. If the method could apply to other databases, then it could be added to the spec (and some databases might raise an error if it is called). -g >---------- >From: Peter Godman[SMTP:pgodman@vgi.com] >Sent: Wednesday, February 12, 1997 12:57 PM >To: Bill Bumgarner >Cc: db-sig@python.org >Subject: Re: [PYTHON DB-SIG] dbi conformant sybase module > >On Wed, 12 Feb 1997, Bill Bumgarner wrote: > >> >> It was asked before-- and spawned a nice conversation, from the look of the >> >> message archive. But the result was not a dbi conformant sybase module... >> so, i'll ask again: >> >> Is anyone working on a python DBI conformant sybase module [Ted?]? If so, >> how much progress has been made and where can I get a hold of the latest >> source so that I can potentially contributed? >> >Hi- > >I've just started work on a DBI conformant ct-lib (as opposed to db-lib) >module. A db-lib but non-DBI module already exists, thanks to Ted. I'm >working on the ct-lib version because I would like to use linux with >Sybase, and sybase only seems to provide ct-lib for linux (in aout >format, yecchh!). > >> Along similar lines; Sybase supports a bulk loading interface-- it is very >> >> convenient when loading a massive quantity of data of known conformance all >> >> at once... anyone added support for the bulk loading (bcp_) interface to >>the >> sybase module? >> >I intend to support bulk loading. Any help, advice, collaboration or >anything else people would like to contribute will appreciated. > >> thanks, >> b.bum >> >Thanks, >Peter Godman > >_______________ >DB-SIG - SIG on Tabular Databases in Python > >send messages to: db-sig@python.org >administrivia to: db-sig-request@python.org >_______________ > _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Mon Feb 17 19:00:38 1997 From: gstein@microsoft.com (Greg Stein) Date: Mon, 17 Feb 1997 11:00:38 -0800 Subject: [PYTHON DB-SIG] Postgres interface Message-ID: I don't believe the PyGres module follows Python's DBAPI, but it certainly works well! >---------- >From: lohrum@inf.fu-berlin.de[SMTP:lohrum@inf.fu-berlin.de] >Sent: Monday, February 17, 1997 9:40 AM >To: ib@procom.de >Cc: db-sig@python.org >Subject: Re: [PYTHON DB-SIG] Postgres interface > >Hi Markus, > >ib> I remember reading about an API compliant Postgres95 interface for >ib> Python, I think it was mentioned in the API Documentation. >ib> >ib> However, I have not been able to find it anywhere around. >ib> >>ib Is it available, usable, still being worked upon, or should I have a try >>at >>ib it myself ??? > >Have a look at: >http://www.cwi.nl/www.python.org/ftp/python/contrib/Database/PyGres95-1.0b.ta >r.gz > >I tried it together with Python Vers.1.2 and Postgres95 Vers.1.09 and it >worked fine. > >Stefan Lohrum > >_______________ >DB-SIG - SIG on Tabular Databases in Python > >send messages to: db-sig@python.org >administrivia to: db-sig-request@python.org >_______________ > _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Wed Feb 19 00:43:51 1997 From: gstein@microsoft.com (Greg Stein) Date: Tue, 18 Feb 1997 16:43:51 -0800 Subject: [PYTHON DB-SIG] Python DBAPI examples and info Message-ID: There have been a number of queries for example code and stuff for using the ODBC module and/or the DBAPI generically. Please feel free to send me HTML fragments/pages and I'll organize those together and place them under the db-sig pages at www.python.org. Example code will work, too, but I'd prefer HTML. Thanx, -g -- Greg Stein, Microsoft Corporation execfile("disclaimer.py") _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Bertil_Reinhammar@ivab.se Wed Feb 19 15:36:20 1997 From: Bertil_Reinhammar@ivab.se (Bertil Reinhammar) Date: Wed, 19 Feb 1997 16:36:20 +0100 Subject: [PYTHON DB-SIG] ANNOUNCE informixdb module Message-ID: <199702191536.QAA29855@mughi.doceye.ivab.se> !!! I'm happy to announce the release of a DB-SIG DBAPI compliant module for Informix v7. I have uploaded a file informixdb.tar.gz to python.org. Please allow for some time for ftpadm@python.org to move it. Download and look in the README for instructions. It should compile right out of the box on Solaris 2.5, HP-UX 10.01 and Win95 with Microsoft Visual C++ 4.2 and Informix ESQL/C 7.20.TE1. Mail complaints to Bertil_Reinhammar@ivab.se and suggestions to db-sig@python.org thanks/ ---BeRe - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bertil Reinhammar IV DocEye AB (Combitech) phn. +46 13 200606 Teknikringen 9 fax. +46 13 214897 S-58330 Linköping bertil_reinhammar@ivab.se Sweden _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Bertil_Reinhammar@ivab.se Thu Feb 20 13:53:22 1997 From: Bertil_Reinhammar@ivab.se (Bertil Reinhammar) Date: Thu, 20 Feb 1997 14:53:22 +0100 Subject: [PYTHON DB-SIG] DbiDate in DBAPI Message-ID: <199702201353.OAA14476@mughi.doceye.ivab.se> !!! The DBAPI DbiDate definition have caused us a couple of problems. 0) There seem to be different definitions of the meaning of type DATE between Oracle and Informix. Possibly also for others. Oracle supplies DATE with year-month-day-hour-minute-second. Informix supplies DATE as days since 18991231 and DATETIME with year-month-day-hour-minute-second-fraction. and allows for any contigous subset of that. Oracle DATE and Informix DATETIME YEAR TO SECOND is the ANSI standard. Informix also have INTERVAL (also ANSI). 1) There is no distinction between DATE and DATETIME. Yes, this is an Informix thing but we use Informix, we use Oracle, we are likely to start using others and we need to write generic code. If other databases have their peculiarities, maybe we can define some general method to make the distinctions. 3) There is no way to indicate the column format for a DATETIME. Assume that I wish to INSERT a record with a DATETIME and I have a dbiDate object with some time info. I then have two options: 1) Form a string representation of a complete INSERT statement and execute. The date info must then be extracted from the dbiDate object and transformed into suitable syntax for the column at hand. If there is a change in the database schema, I have to find all places in my code to make a change. 2) Tweak the implementation to retrieve the column definition from database system tables and form a correct insert value (and possibly coercing the time info to fit). We have encountered cases where the database is defined by the customer and we have been forced to write quite ugly code to work around this lack of information and control. Also, if I wish to write some generic code handling DATETIMES, I'm stuck since all I have is time since unix epoch and can't make any distinction between the case YEAR TO DAY and the case YEAR TO SECOND and the time happens to be exactly midnight a certain day. In the former case, there is little meaning to allow code to add 3 hours and 34 minutes which is quite valid in the latter. 3) There is no way to denote a fraction of a second. Ok, one could live without it but its defined by ANSI (for INTERVAL) and there will surely pop up needs for it so why not try to support it. Yes, I understand that much of this was considered as part of the basis for the definition as it is. I just feel the definition inadequate and would very much like to see it improved instead of just supplying extensions for the Informix module (contradicting DBAPI def) or worse, supply another module with its own api. (We have one.) So that's my observations. How may we improve ? I can see two ways: 1) Extend dbiDate to take constructor arguments defining type (DATE vs DATETIME) and span (YEAR TO SECOND et al). For symmetry we need a type attribute and a span attribute to allow us to see how the column is defined. On top of this we may create wrappers to our liking. 2) Define a new class with fullblown utilities. (Hmm, I remember some discussion on a datetime module but that didn't deal with database needs or ...) Extending dbiDate as indicated should be simple enough. Defining a new class may lead us to eternal discussions before we settle what we want in it. ---BeRe - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bertil Reinhammar IV DocEye AB (Combitech) phn. +46 13 200606 Teknikringen 9 fax. +46 13 214897 S-58330 Linköping bertil_reinhammar@ivab.se Sweden _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From mlorton@microsoft.com Thu Feb 20 19:28:42 1997 From: mlorton@microsoft.com (Michael Lorton) Date: Thu, 20 Feb 1997 11:28:42 -0800 Subject: [PYTHON DB-SIG] DbiDate in DBAPI Message-ID: Dates in Python really should have a "precision" , the way they do in real life. 1996 is a date, right? It just has a precision of one year. There are some provocative questions: 1. What does equality mean? Does "noon today" "equal" 1997-02-20 12:00:00.0. Does it equal "today"? 1997? 2. If we allow (a form of) date-equality that means inclusion, D1 == D2 IFF ( D1 contains D2 or D2 contains D1), what about timezones? By this definition 1997 in Seattle does not equal 1997 in Amsterdam, since there is, what, nine hours overhand on each side. 3. What about total-ordering? Is 1997 in Amsterdam "less than" New Years Day in Seattle (because it started first), "equal to" (because it overlaps) or "greater than" (because it ends last)? M. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jeff@ollie.clive.ia.us Thu Feb 20 20:23:10 1997 From: jeff@ollie.clive.ia.us (Jeffrey C. Ollie) Date: Thu, 20 Feb 1997 14:23:10 -0600 Subject: [PYTHON DB-SIG] DbiDate in DBAPI In-Reply-To: Your message of "Thu, 20 Feb 1997 11:28:42 PST." Message-ID: <199702202023.OAA22132@worf.netins.net> -----BEGIN PGP SIGNED MESSAGE----- On Thu, 20 Feb 1997 11:28:42 -0800, mlorton@microsoft.com writes: > >Dates in Python really should have a "precision" , the way they do in >real life. 1996 is a date, right? It just has a precision of one year. Yes, a very interesting suggestion. >There are some provocative questions: > >1. What does equality mean? Does "noon today" "equal" 1997-02-20 >12:00:00.0. Does it equal "today"? 1997? There should be a module-level global variable that switches between precise matching and non-precise matching. By exact matching, I mean that when comparing two dates, the precisions must be equal and the dates must match within that precision. Comparisons of dates with different precisions would raise an exception. With non-precise matching, the date with the higher precision would be converted to the lower precision and then the comparison would be made. >2. If we allow (a form of) date-equality that means inclusion, D1 == D2 > IFF ( D1 contains D2 or D2 contains D1), what about timezones? By this >definition 1997 in Seattle does not equal 1997 in Amsterdam, since there >is, what, nine hours overhand on each side. > >3. What about total-ordering? Is 1997 in Amsterdam "less than" New >Years Day in Seattle (because it started first), "equal to" (because it >overlaps) or "greater than" (because it ends last)? The internal representation of a date should always be UTC. That completely eliminates this kind of confusion. Conversion to/from local time should be supported for the convenience of humans only. [A copy of the headers and the PGP signature follow.] Date: Thu, 20 Feb 1997 14:23:10 -0600 From: "Jeffrey C. Ollie" In-reply-to: Your message of "Thu, 20 Feb 1997 11:28:42 PST." Subject: Re: [PYTHON DB-SIG] DbiDate in DBAPI To: db-sig@python.org -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news. iQCVAwUBMwyyt5wkOQz8sbZFAQH5twP/btXxamurfj+DWBvhYPYPaTB6CT/jJe4Z TBeH0zeVWc7QJj29xBtKlj5FNy9YZGZ/PM15idaWoF1UlxXKYFIKVggaeQeBDQ2X 3B81VaGDeOTGoBJ3mHm76MR9c4fDnKRgVrxb+2apgxV/QEiGWc9N76n5Stp3rPyw QW3vzXPWaXY= =Okba -----END PGP SIGNATURE----- -- Jeffrey C. Ollie | Should Work Now (TM) Python Hacker, Mac Lover | _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From mlorton@microsoft.com Fri Feb 21 00:17:01 1997 From: mlorton@microsoft.com (Michael Lorton) Date: Thu, 20 Feb 1997 16:17:01 -0800 Subject: [PYTHON DB-SIG] DbiDate in DBAPI Message-ID: > >On Thu, 20 Feb 1997 11:28:42 -0800, mlorton@microsoft.com writes: >> >>Dates in Python really should have a "precision" , the way they do in >>real life. 1996 is a date, right? It just has a precision of one year. >[Jeff Ollie answers] >Yes, a very interesting suggestion. > >>There are some provocative questions: >> >>1. What does equality mean? Does "noon today" "equal" 1997-02-20 >>12:00:00.0. Does it equal "today"? 1997? > >There should be a module-level global variable that switches between >precise matching and non-precise matching. By exact matching, I mean that >when comparing two dates, the precisions must be equal and the dates must >match within that precision. Comparisons of dates with different precisions >would raise an exception. >With non-precise matching, the date with the higher precision would be >converted to the lower precision and then the comparison would be made. > >A nit: better to have two functions than a non-local effect over a local >expression. > >>2. If we allow (a form of) date-equality that means inclusion, D1 == D2 >> IFF ( D1 contains D2 or D2 contains D1), what about timezones? By this >>definition 1997 in Seattle does not equal 1997 in Amsterdam, since there >>is, what, nine hours overhand on each side. >> >>3. What about total-ordering? Is 1997 in Amsterdam "less than" New >>Years Day in Seattle (because it started first), "equal to" (because it >>overlaps) or "greater than" (because it ends last)? > >The internal representation of a date should always be UTC. That >completely eliminates this kind of confusion. > So "today" (i.e. 1997-02-20 00:00:00.0 - 1997-02-20 23:59:59.99 PST for me) cannot be represented in this system? That might be reasonable >restriction, as many other spans of time are not representable. > >Conversion to/from local time should be supported for the convenience >of humans only. > >Does anyone on this list qualify? > >M. > _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From klm@CNRI.Reston.Va.US Wed Feb 26 21:04:16 1997 From: klm@CNRI.Reston.Va.US (Ken Manheimer) Date: Wed, 26 Feb 1997 16:04:16 -0500 (EST) Subject: [PYTHON DB-SIG] Re: informixdb.tar.gz on incoming In-Reply-To: <199702201421.PAA14865@mughi.doceye.ivab.se> Message-ID: On Thu, 20 Feb 1997, Bertil Reinhammar wrote: > I just uploaded a bugfix for my informixdb.tar.gz. I've put the informixdb.tar.gz-bugfix2 in place as and the README, as well. (I also added links in the db-sig index page, since it uses the Python DB API.) _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Fri Feb 28 22:34:24 1997 From: gstein@microsoft.com (Greg Stein) Date: Fri, 28 Feb 1997 14:34:24 -0800 Subject: [PYTHON DB-SIG] Re: informixdb.tar.gz on incoming Message-ID: Great. I was pending an update of the index page because I hadn't seen the module itself appear (only the non-dbapi module was there). In any case, thanks Ken! -g >---------- >From: Ken Manheimer[SMTP:klm@CNRI.Reston.Va.US] >Sent: Wednesday, February 26, 1997 1:04 PM >To: Bertil Reinhammar >Cc: ftpmaster@python.org; db-sig@python.org >Subject: [PYTHON DB-SIG] Re: informixdb.tar.gz on incoming > >On Thu, 20 Feb 1997, Bertil Reinhammar wrote: > >> I just uploaded a bugfix for my informixdb.tar.gz. > >I've put the informixdb.tar.gz-bugfix2 in place as > > > >and the README, as well. (I also added links in the db-sig index page, >since it uses the Python DB API.) > > >_______________ >DB-SIG - SIG on Tabular Databases in Python > >send messages to: db-sig@python.org >administrivia to: db-sig-request@python.org >_______________ > _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Wed Feb 19 00:43:51 1997 From: gstein@microsoft.com (Greg Stein) Date: Tue, 18 Feb 1997 16:43:51 -0800 Subject: [PYTHON DB-SIG] Python DBAPI examples and info Message-ID: There have been a number of queries for example code and stuff for using the ODBC module and/or the DBAPI generically. Please feel free to send me HTML fragments/pages and I'll organize those together and place them under the db-sig pages at www.python.org. Example code will work, too, but I'd prefer HTML. Thanx, -g -- Greg Stein, Microsoft Corporation execfile("disclaimer.py") _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________