From zen@shangri-la.dropbear.id.au Fri Nov 2 07:02:37 2001 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Fri, 2 Nov 2001 18:02:37 +1100 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BDD3E84.6FEEC4E5@lemburg.com> Message-ID: <99450F98-CF5F-11D5-A838-000393031882@shangri-la.dropbear.id.au> On Monday, October 29, 2001, at 10:33 PM, M.-A. Lemburg wrote: > > Python-Version: 2.3 2.2, or maybe even 1.5.2? If this gets finalized in time, we may be able to get the 2.0 DB API spec marked up and shipped with the Python 2.2 documentation (I'll volunteer to do the mark up). -- Stuart Bishop http://shangri-la.dropbear.id.au/ From maynard@mpi-cbg.de Fri Nov 2 10:34:52 2001 From: maynard@mpi-cbg.de (Gary Maynard) Date: Fri, 2 Nov 2001 11:34:52 +0100 Subject: [DB-SIG] Python database API 2.0/returning Column names with data Message-ID: <004701c1638a$01e6e3b0$1103010a@Whiskey> This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C16392.63620DB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI, We are trying to implement a method whereby we can return data from = the database in key value dictionary pairs. so for example we have a table something like this: Table: Address Name varchar(20), Street varchar(20), Town varchar(20), ccode char(2) and we want to return the data into a dictionary so that we also have = access to the column title. For example, let's say we query the = database with something like this: result =3D cursor.fetchall("select * from Address") Then we'd like to put the data from result into another data object, = call it sorted_result. We'd like to include the column names in this = object such that we could obtain any piece of data by giving it the row = number and column name. So, if we wanted to obtain the Street of the = 6th row, we would say something like: sorted_result [6]['Street'] And if we wanted to iterate over all the streets we can do: for x in result: do stuff with result[x]['Street'] There seems to be fairly standard ways of doing this in DBI = (selectrow_hashref) and ODBC (Datahash), but I can't seem to make it = work with this API. Any suggestions? thanks Gary ------=_NextPart_000_0044_01C16392.63620DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
HI,
  We are trying to implement a = method whereby=20 we can return data from the database in key value dictionary = pairs.
 
so for example we have a table = something like=20 this:
 
Table: Address
Name varchar(20),
Street varchar(20),
Town varchar(20),
ccode char(2)
 
and we want to return the data into a = dictionary so=20 that we also have access to the column title.  For example, let's = say we=20 query the database with something like this:
 
result =3D cursor.fetchall("select * = from=20 Address")
 
Then we'd like to put the data from = result into=20 another data object, call it sorted_result.  We'd like to include = the=20 column names in this object such that we could obtain any piece of data = by=20 giving it the row number and column name.  So, if we wanted to = obtain the=20 Street of the 6th row, we would say something like:
 
sorted_result = [6]['Street']
 
And if we wanted to iterate over all = the streets we=20 can do:
 
for x in result:
   do stuff with=20 result[x]['Street']
 
There seems to be fairly standard ways = of doing=20 this in DBI (selectrow_hashref) and ODBC (Datahash), but I can't seem to = make it=20 work with this API.
 
Any suggestions?
thanks
Gary
------=_NextPart_000_0044_01C16392.63620DB0-- From darcy@druid.net Fri Nov 2 12:03:40 2001 From: darcy@druid.net (D'Arcy J.M. Cain) Date: Fri, 2 Nov 2001 07:03:40 -0500 (EST) Subject: [DB-SIG] Python database API 2.0/returning Column names with data In-Reply-To: from "Gary Maynard" at Nov 02, 2001 11:34:52 AM Message-ID: <20011102120340.EB4921A6B@druid.net> Thus spake Gary Maynard > We are trying to implement a method whereby we can return data from = > the database in key value dictionary pairs. > > so for example we have a table something like this: > > Table: Address > Name varchar(20), > Street varchar(20), > Town varchar(20), > ccode char(2) > > and we want to return the data into a dictionary so that we also have = > access to the column title. For example, let's say we query the = > database with something like this: > > result =3D cursor.fetchall("select * from Address") > > Then we'd like to put the data from result into another data object, = > call it sorted_result. We'd like to include the column names in this = > object such that we could obtain any piece of data by giving it the row = > number and column name. So, if we wanted to obtain the Street of the = > 6th row, we would say something like: > > sorted_result [6]['Street'] This is exactly what the dictresult() method in "Classic" PyGreSQL does. See http://druid.net/pygresql/ for details. -- 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 mal@lemburg.com Fri Nov 2 16:04:09 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 02 Nov 2001 17:04:09 +0100 Subject: [DB-SIG] Python database API 2.0/returning Column names with data References: <004701c1638a$01e6e3b0$1103010a@Whiskey> Message-ID: <3BE2C3F9.DA0CEA1E@lemburg.com> > Gary Maynard wrote: > > HI, > We are trying to implement a method whereby we can return data from > the database in key value dictionary pairs. > > so for example we have a table something like this: > > Table: Address > Name varchar(20), > Street varchar(20), > Town varchar(20), > ccode char(2) > > and we want to return the data into a dictionary so that we also have > access to the column title. For example, let's say we query the > database with something like this: > > result = cursor.fetchall("select * from Address") > > Then we'd like to put the data from result into another data object, > call it sorted_result. We'd like to include the column names in this > object such that we could obtain any piece of data by giving it the > row number and column name. So, if we wanted to obtain the Street of > the 6th row, we would say something like: > > sorted_result [6]['Street'] > > And if we wanted to iterate over all the streets we can do: > > for x in result: > do stuff with result[x]['Street'] > > There seems to be fairly standard ways of doing this in DBI > (selectrow_hashref) and ODBC (Datahash), but I can't seem to make it > work with this API. > > Any suggestions? Please scan the DB-SIG archives for discussions and links on this topic: there are a few tools out there to wrap the results of .fecthxxx() into dictionaries. Easiest to use is probably dtuple.py by Greg Stein. We should really add a note about this to the DB API -- this question is becoming a FAQ. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Fri Nov 2 16:05:42 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 02 Nov 2001 17:05:42 +0100 Subject: [DB-SIG] Optional DB API Extensions References: <99450F98-CF5F-11D5-A838-000393031882@shangri-la.dropbear.id.au> Message-ID: <3BE2C456.DBBB105B@lemburg.com> Stuart Bishop wrote: > > On Monday, October 29, 2001, at 10:33 PM, M.-A. Lemburg wrote: > > > > Python-Version: 2.3 > > 2.2, or maybe even 1.5.2? > > If this gets finalized in time, we may be able to get the > 2.0 DB API spec marked up and shipped with the Python 2.2 > documentation (I'll volunteer to do the mark up). Fred will know what the time line is for 2.2 documentation and whether the DB API fits in there... Fred ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From fdrake@acm.org Fri Nov 2 16:35:07 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 2 Nov 2001 11:35:07 -0500 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BE2C456.DBBB105B@lemburg.com> References: <99450F98-CF5F-11D5-A838-000393031882@shangri-la.dropbear.id.au> <3BE2C456.DBBB105B@lemburg.com> Message-ID: <15330.52027.988583.120100@grendel.zope.com> M.-A. Lemburg writes: > Fred will know what the time line is for 2.2 documentation and > whether the DB API fits in there... Fred ? I don't follow the db-sig, so perhaps I'm missing some context. Given that there are no DB-API implementations in the standard library, why should the DB-API specification be included in the documentation? On first thought, I'd expect it to appear in the standard documentation when an implementation is shipped as part of the standard library. If there's something I'm missing on this, please feel free to bring me up to speed. Regarding the schedule, I'm hesitant to add any more substantial components beyond what's already being worked on. We've added a lot of material for this release (the compiler and email packages, and Tkinter/GUI chapter is being prepared), and those have had far too little editorial review as it is. I'll try to take a look at the DB-API spec sometime next week, but I'm afraid my evening hours are largely unavailable at the moment due to some other projects. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From TKeating@origin.ea.com Fri Nov 2 16:54:40 2001 From: TKeating@origin.ea.com (Keating, Tim) Date: Fri, 2 Nov 2001 10:54:40 -0600 Subject: [DB-SIG] Python database API 2.0/returning Column names with data Message-ID: <2292DBED5A978A498EABCCE95524499E0281D7E5@osi-postal.osi.ad.ea.com> > for x in result: > do stuff with result[x]['Street'] I think you probably meant: for x in result: do stuff with x[ 'Street' ] Right? TK From mal@lemburg.com Fri Nov 2 17:37:32 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 02 Nov 2001 18:37:32 +0100 Subject: [DB-SIG] Optional DB API Extensions References: <99450F98-CF5F-11D5-A838-000393031882@shangri-la.dropbear.id.au> <3BE2C456.DBBB105B@lemburg.com> <15330.52027.988583.120100@grendel.zope.com> Message-ID: <3BE2D9DC.33F6E3DA@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Fred will know what the time line is for 2.2 documentation and > > whether the DB API fits in there... Fred ? > > I don't follow the db-sig, so perhaps I'm missing some context. > Given that there are no DB-API implementations in the standard > library, why should the DB-API specification be included in the > documentation? Even though there are no standard DB API modules in the dist, these informative PEPs (the DB-API was converted to a informative PEP some time ago) would be of benefit to the Python user. Perhaps we could add a new PEP section to the docs somewhere ?! (One which includes informative and accepted final PEPs ?) > On first thought, I'd expect it to appear in the > standard documentation when an implementation is shipped as part of > the standard library. > If there's something I'm missing on this, please feel free to bring > me up to speed. > Regarding the schedule, I'm hesitant to add any more substantial > components beyond what's already being worked on. We've added a lot > of material for this release (the compiler and email packages, and > Tkinter/GUI chapter is being prepared), and those have had far too > little editorial review as it is. > I'll try to take a look at the DB-API spec sometime next week, but > I'm afraid my evening hours are largely unavailable at the moment due > to some other projects. Ok, so let's put this off for this release and try to go for the next one. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From db3l@fitlinxx.com Fri Nov 2 22:10:38 2001 From: db3l@fitlinxx.com (David Bolen) Date: Fri, 2 Nov 2001 17:10:38 -0500 Subject: [DB-SIG] Python database API 2.0/returning Column names with data Message-ID: Gary Maynard [maynard@mpi-cbg.de] writes: > result = cursor.fetchall("select * from Address") > > Then we'd like to put the data from result into another data object, > call it sorted_result. We'd like to include the column names in this > object such that we could obtain any piece of data by giving it the > row number and column name. So, if we wanted to obtain the Street of > the 6th row, we would say something like: > > sorted_result [6]['Street'] Others have pointed out some of the externally available modules (e.g., dtuple), but it's also pretty simple to just write your own function to do it. Here's a sample of a function that is given a cursor with a command previously executed, and automatically processes the fetchall() into a list of dictionaries. Far less generic than something like dtuple, but it does meet your above goals: - - - - - - - - - - - - - - - - - - - - - - - - - def QueryToDictList(cursor): """QueryToDict(cursor) Execute query on the supplied cursor and return the result as a list of dictionaries, using the cursor description as the keys in each dict""" result = [] rows = cursor.fetchall() for currow in rows: rowdict = {} for curcol in range(0,len(cursor.description)): rowdict[cursor.description[curcol][0]] = currow[curcol] result.append(rowdict) return result - - - - - - - - - - - - - - - - - - - - - - - - - This is a specific implementation that uses precisely the same case for the dictionary keys as that of the column names. With this, you would do something like: sorted_result = QueryToDictList(cursor) and then you could use sorted_result as desired, either: sorted_result[6]['Street'] or for x in sorted_result: do stuff with x['Street'] My understanding for why something like this isn't part of the DB API is that there is or was debate about various implementation details (e.g., choices about case sensitivity of dictionary keys versus column names) so it was easier to leave it to something layered on top of the API rather than as part of the API proper. -- David /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ From dario@ita.chalmers.se Sat Nov 3 11:19:37 2001 From: dario@ita.chalmers.se (=?iso-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Sat, 3 Nov 2001 12:19:37 +0100 Subject: [DB-SIG] Current status of Gadfly References: <3BAA73BD.5090109@crosswinds.net> Message-ID: <007201c16459$6c4431c0$2135b5d4@ita.chalmers.se> ----- Original Message ----- From: "Andy Todd" > I'll email Aaron Watters anyway and see what he has to say, if it's > possible to patch the Gadfly sources he releases it may be a worthwhile > exercise. So, did you get any reaction from Aaron Watters? /dario - -------------------------------------------------------------------- Dario Lopez-Kästen Systems Developer Chalmers Univ. of Technology dario@ita.chalmers.se ICQ will yield no hits IT Systems & Services From Billy G. Allie" Message-ID: <200111031820.fA3IKgF09142@bajor.mug.org> --==_Exmh_-1873560944P Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable David Bolen writes: > Gary Maynard [maynard@mpi-cbg.de] writes: > = > > result =3D cursor.fetchall("select * from Address") > > = > > Then we'd like to put the data from result into another data object, > > call it sorted_result. We'd like to include the column names in this= > > object such that we could obtain any piece of data by giving it the > row number and column name. So, if we wanted to obtain the Street of > > the 6th row, we would say something like: > > = > > sorted_result [6]['Street'] > = > Others have pointed out some of the externally available modules > (e.g., dtuple), but it's also pretty simple to just write your own > function to do it. Here's a sample of a function that is given > a cursor with a command previously executed, and automatically > processes the fetchall() into a list of dictionaries. Far less > generic than something like dtuple, but it does meet your above goals: Another possibility is to use the PgResultSet object from pyPgSQL = (http://pypgsql.sourceforge.net). This object acts as a list or a dictio= nary. = It also exposes the result columns as attributes by column name, making = it = possible to reference columns using: given: result =3D cursor.fetchall("select * from Address") 1. result[6][2] /* accessed as a list */ 2. result[6]['street'] /* accessed as a dictionary */ 3. result[6].street /* accessed as an attribute */ -- = ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 | --==_Exmh_-1873560944P Content-Type: application/pgp-signature -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable David Bolen writes: > Gary Maynard [maynard@mpi-cbg.de] writes: > = > > result =3D cursor.fetchall("select * from Address") > > = > > Then we'd like to put the data from result into another data object, > > call it sorted_result. We'd like to include the column names in this= > > object such that we could obtain any piece of data by giving it the > row number and column name. So, if we wanted to obtain the Street of > > the 6th row, we would say something like: > > = > > sorted_result [6]['Street'] > = > Others have pointed out some of the externally available modules > (e.g., dtuple), but it's also pretty simple to just write your own > function to do it. Here's a sample of a function that is given > a cursor with a command previously executed, and automatically > processes the fetchall() into a list of dictionaries. Far less > generic than something like dtuple, but it does meet your above goals: Another possibility is to use the PgResultSet object from pyPgSQL = (http://pypgsql.sourceforge.net). This object acts as a list or a dictio= nary. = It also exposes the result columns as attributes by column name, making = it = possible to reference columns using: given: result =3D cursor.fetchall("select * from Address") 1. result[6][2] /* accessed as a list */ 2. result[6]['street'] /* accessed as a dictionary */ 3. result[6].street /* accessed as an attribute */ - -- = ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (UnixWare) Comment: Exmh version 2.2 06/23/2000 iD8DBQE75DV6nmIkMXoVVdURAgj1AKC/xm2exi2F59FcTip4Zrx7/wpkwQCg1nin ZzU+wOrn8LuIqcM8wVLHSIg= =I8uG -----END PGP SIGNATURE----- --==_Exmh_-1873560944P-- From maynard@mpi-cbg.de Sun Nov 4 10:38:28 2001 From: maynard@mpi-cbg.de (Gary Maynard) Date: Sun, 4 Nov 2001 11:38:28 +0100 Subject: [DB-SIG] Python database API 2.0/returning Column names with data References: Message-ID: <016301c1651c$d710b2d0$1103010a@Whiskey> Thanks everybody for your help with this. I got it working without too much trouble after I read your messages. As a Python Newbie though, may I suggest that this kind if information be made more readily available? the Cursor.description function that is required to do this is not listed in the API and thus seems almost to be an undocumented feature. Gary From mal@lemburg.com Sun Nov 4 12:37:19 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 04 Nov 2001 13:37:19 +0100 Subject: [DB-SIG] Python database API 2.0/returning Column names with data References: <016301c1651c$d710b2d0$1103010a@Whiskey> Message-ID: <3BE5367F.71D33255@lemburg.com> Gary Maynard wrote: > > Thanks everybody for your help with this. I got it working without too much > trouble after I read your messages. > > As a Python Newbie though, may I suggest that this kind if information be > made more readily available? the Cursor.description function that is > required to do this is not listed in the API and thus seems almost to be an > undocumented feature. Oh, it is: """ Cursor Objects should respond to the following methods and attributes: description This read-only attribute is a sequence of 7-item sequences. Each of these sequences contains information describing one result column: (name, type_code, display_size, internal_size, precision, scale, null_ok). The first two items (name and type_code) are mandatory, the other five are optional and must be set to None if meaningfull values are not provided. This attribute will be None for operations that do not return rows or if the cursor has not had an operation invoked via the executeXXX() method yet. The type_code can be interpreted by comparing it to the Type Objects specified in the section below. """ But you're right in that this question often comes up and there's no hint to the solution in the DB API. I'll fix that with the next revision of the 2.0 API. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From david@dataovation.com Sun Nov 4 14:56:57 2001 From: david@dataovation.com (David A McInnis) Date: Sun, 4 Nov 2001 06:56:57 -0800 Subject: [DB-SIG] Python database API 2.0/returning Column names with data In-Reply-To: <016301c1651c$d710b2d0$1103010a@Whiskey> Message-ID: I found another one myself, for MySQLdb (I am using MySQL). It appears that cursorclass= is undocumented as well. If you set cursorclass=MySQLdb.cursors.DictCursor, a dictionary is returned which contains the row names. db1 = MySQLdb.connect(user = "username", passwd="password", host= "host", db = "database", cursorclass=MySQLdb.cursors.DictCursor) c1 = db1.cursor() c1.execute("""SELECT * from table where email = %s""", 'david@topsites.net',) row1 = c1.fetchone() print row1['acctno'] print row1['email'] print row1['amt'] -----Original Message----- From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf Of Gary Maynard Sent: Sunday, November 04, 2001 2:38 AM To: db-sig@python.org Subject: Re: [DB-SIG] Python database API 2.0/returning Column names with data Thanks everybody for your help with this. I got it working without too much trouble after I read your messages. As a Python Newbie though, may I suggest that this kind if information be made more readily available? the Cursor.description function that is required to do this is not listed in the API and thus seems almost to be an undocumented feature. Gary _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig From andy@dustman.net Sun Nov 4 15:54:28 2001 From: andy@dustman.net (Andy Dustman) Date: 04 Nov 2001 10:54:28 -0500 Subject: [DB-SIG] Python database API 2.0/returning Column names with data In-Reply-To: References: Message-ID: <1004889268.22704.3.camel@chef.comstar.net> On Sun, 2001-11-04 at 09:56, David A McInnis wrote: > I found another one myself, for MySQLdb (I am using MySQL). > > It appears that cursorclass= is undocumented as well. > > If you set cursorclass=MySQLdb.cursors.DictCursor, a dictionary is returned > which contains the row names. > > db1 = MySQLdb.connect(user = "username", passwd="password", host= "host", db > = "database", cursorclass=MySQLdb.cursors.DictCursor) > > c1 = db1.cursor() > c1.execute("""SELECT * from table where email = %s""", > 'david@topsites.net',) > > row1 = c1.fetchone() > print row1['acctno'] > print row1['email'] > print row1['amt'] MySQLdb's cursorclass is not documented in the DB API because it is a non-standard extension. It is, however, well-documented in the MySQLdb documentation. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From thomas@fleasale.com Mon Nov 5 18:02:11 2001 From: thomas@fleasale.com (Thomas Garcia) Date: Mon, 05 Nov 2001 13:02:11 -0500 Subject: [DB-SIG] Feel better, Look better, loose weight, build muscle, and make Money! Message-ID: How would you like to manage and loose weight in a safe way? No more speed, or those quick fixes that can be bad for you. Come and pay me a visit at WWW.Fleasale.com. And check out AdvoCare, a revolutionary line of products that can change your life. These products are used by the US Olympic Wrestling team, and The Russian Olympic teams. And the list of endorsers is Very Impressive because the product works, and makes you feel great! There are products for putting on muscle, loosing weight, weight management, supplements, Vitamins exc... Or become a Distributor, and receive an extra 20% off, and have the ability to make an extra income and help people feel better at the same time. WWW.FLEASALE.COM Thank You Thomas Garcia AdvoCare Financial Freedom is just around the corner! at www.Fleasale.com From TKeating@origin.ea.com Mon Nov 5 18:10:01 2001 From: TKeating@origin.ea.com (Keating, Tim) Date: Mon, 5 Nov 2001 12:10:01 -0600 Subject: [DB-SIG] Feel better, Look better, loose weight, build muscle , and make Money! Message-ID: <2292DBED5A978A498EABCCE95524499E0281D7F2@osi-postal.osi.ad.ea.com> Could someone please boot this jackass off the list? Thank you. > -----Original Message----- > From: Thomas Garcia [mailto:thomas@fleasale.com] > Sent: Monday, November 05, 2001 12:02 PM > To: db-sig@python.org > Subject: [DB-SIG] Feel better, Look better, loose weight, > build muscle, > and make Money! > > > How would you like to manage and loose weight in a safe > way? No > more speed, or those quick fixes that can be bad for you. > Come and pay > me a visit at WWW.Fleasale.com. And check out AdvoCare, a > revolutionary line of products that can change your life. These > products are used by the US Olympic Wrestling team, and The Russian > Olympic teams. And the list of endorsers is Very Impressive because > the product works, and makes you feel great! There are products for > putting on muscle, loosing weight, weight management, supplements, > Vitamins exc... > Or become a Distributor, and receive an extra 20% off, and have the > ability to make an extra income and help people feel better > at the same > time. > WWW.FLEASALE.COM > Thank You > Thomas Garcia > > AdvoCare Financial Freedom is just around the corner! > at www.Fleasale.com > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > From chris@onca.catsden.net Mon Nov 5 18:58:19 2001 From: chris@onca.catsden.net (chris@onca.catsden.net) Date: Mon, 5 Nov 2001 10:58:19 -0800 (PST) Subject: [DB-SIG] Feel better, Look better, loose weight, build muscle , and make Money! In-Reply-To: <2292DBED5A978A498EABCCE95524499E0281D7F2@osi-postal.osi.ad.ea.com> Message-ID: On Mon, 5 Nov 2001, Keating, Tim wrote: > Could someone please boot this jackass off the list? Thank you. I seriously doubt he's ON the list. Just your stock standard spam, we need to turn on 'member posting only' :) ("`-/")_.-'"``-._ Ch'marr, a.k.a. . . `; -._ )-;-,_`) Chris Cogdon (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' FC1.3: FFH3cmA+>++C++D++H++M++P++R++T+++WZ++Sm++ ((,.-' ((,/ fL RLCT acl+++d++e+f+++h++i++++jp-sm++ From akuchlin@mems-exchange.org Mon Nov 5 19:54:17 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 5 Nov 2001 14:54:17 -0500 Subject: [DB-SIG] List spam In-Reply-To: ; from chris@onca.catsden.net on Mon, Nov 05, 2001 at 10:58:19AM -0800 References: <2292DBED5A978A498EABCCE95524499E0281D7F2@osi-postal.osi.ad.ea.com> Message-ID: <20011105145416.K16599@ute.mems-exchange.org> On Mon, Nov 05, 2001 at 10:58:19AM -0800, chris@onca.catsden.net wrote: >I seriously doubt he's ON the list. Just your stock standard spam, we need >to turn on 'member posting only' :) Amazingly, he actually was subscribed to the list. I've removed the original poster and enabled 'member posting only', but I suspect it'll get annoying and be turned off again before too long. For example, your post had to be manually approved for some reason. --amk From gstein@lyra.org Tue Nov 6 07:18:17 2001 From: gstein@lyra.org (Greg Stein) Date: Mon, 5 Nov 2001 23:18:17 -0800 Subject: [DB-SIG] Python database API 2.0/returning Column names with data In-Reply-To: ; from db3l@fitlinxx.com on Fri, Nov 02, 2001 at 05:10:38PM -0500 References: Message-ID: <20011105231817.A17149@lyra.org> On Fri, Nov 02, 2001 at 05:10:38PM -0500, David Bolen wrote: >... > result = [] > rows = cursor.fetchall() > for currow in rows: > rowdict = {} > for curcol in range(0,len(cursor.description)): > rowdict[cursor.description[curcol][0]] = currow[curcol] > result.append(rowdict) > > return result > > - - - - - - - - - - - - - - - - - - - - - - - - - > > This is a specific implementation that uses precisely the same case > for the dictionary keys as that of the column names. However, unlike dtuple.py, you end up scanning the *entire* list of records, creating a dictionary for every row, and then appending that to a list (which may have to be resized multiple times). When I wrote dtuple umpteen million years ago, I had approached the problem similarly to what you did above. In real life scenarios, it just blew. Profiling the code showed the bottleneck was that loop. So dtuple was built to have O(1) for creation, and defer the costly work to access time. And even then, it doesn't create objects -- it just looks them up. >... > My understanding for why something like this isn't part of the DB API > is that there is or was debate about various implementation details > (e.g., choices about case sensitivity of dictionary keys versus column > names) so it was easier to leave it to something layered on top of the > API rather than as part of the API proper. There are a million choices in implementation. Various tradeoffs in space and time, selections of algorithms, etc. And the simple fact: it is *easy* to implement helpers like this in Python. There is no reason to make each and every DBAPI provider implement this stuff. Then deal with the eventual bugs and (therefore) variances in the resulting API. DBAPI stresses simplicity for the provider's implementation. The more complex stuff is left where it should be: in the hands of the client and the Python-level code. DBAPI also avoids the fallacy that you can create a single API that can cover *all* databases. That isn't possible, so it takes a middle road of flexibility and simplicity. Providers can implement that spec and provider a very useful tool to Python users. They can also go well beyond that to provide capabilities specific to their database (mxODBC and MySQLdb both do this very well), allowing Python developers to custom-tailer their apps to take advantage of the unique features of those modules. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Nov 6 07:25:30 2001 From: gstein@lyra.org (Greg Stein) Date: Mon, 5 Nov 2001 23:25:30 -0800 Subject: [DB-SIG] Feel better, Look better, loose weight, build muscle , and make Money! In-Reply-To: ; from chris@onca.catsden.net on Mon, Nov 05, 2001 at 10:58:19AM -0800 References: <2292DBED5A978A498EABCCE95524499E0281D7F2@osi-postal.osi.ad.ea.com> Message-ID: <20011105232530.B17149@lyra.org> On Mon, Nov 05, 2001 at 10:58:19AM -0800, chris@onca.catsden.net wrote: > On Mon, 5 Nov 2001, Keating, Tim wrote: > > > Could someone please boot this jackass off the list? Thank you. > > I seriously doubt he's ON the list. Just your stock standard spam, we need > to turn on 'member posting only' :) That smiley makes me doubt you were serious, but to clarify: 'member posting only' is *off* because we want random non-subscribed users to be able to post here for help. Throwing the hurdle of subscribing to the list will just get in their way. Note that a lot of spam is actually captured by Mailman because very little of it lists the mailing list in the To: (or CC:) headers. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Nov 6 07:26:08 2001 From: gstein@lyra.org (Greg Stein) Date: Mon, 5 Nov 2001 23:26:08 -0800 Subject: [DB-SIG] List spam In-Reply-To: <20011105145416.K16599@ute.mems-exchange.org>; from akuchlin@mems-exchange.org on Mon, Nov 05, 2001 at 02:54:17PM -0500 References: <2292DBED5A978A498EABCCE95524499E0281D7F2@osi-postal.osi.ad.ea.com> <20011105145416.K16599@ute.mems-exchange.org> Message-ID: <20011105232607.C17149@lyra.org> On Mon, Nov 05, 2001 at 02:54:17PM -0500, Andrew Kuchling wrote: > On Mon, Nov 05, 2001 at 10:58:19AM -0800, chris@onca.catsden.net wrote: > >I seriously doubt he's ON the list. Just your stock standard spam, we need > >to turn on 'member posting only' :) > > Amazingly, he actually was subscribed to the list. I've removed the > original poster and enabled 'member posting only', but I suspect it'll > get annoying and be turned off again before too long. For example, > your post had to be manually approved for some reason. See my previous post about member posting. That is a *really* bad idea for this list. Way way bad. -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Tue Nov 6 08:43:42 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 06 Nov 2001 09:43:42 +0100 Subject: [DB-SIG] List spam References: <2292DBED5A978A498EABCCE95524499E0281D7F2@osi-postal.osi.ad.ea.com> <20011105145416.K16599@ute.mems-exchange.org> <20011105232607.C17149@lyra.org> Message-ID: <3BE7A2BE.90407566@lemburg.com> Greg Stein wrote: > > On Mon, Nov 05, 2001 at 02:54:17PM -0500, Andrew Kuchling wrote: > > On Mon, Nov 05, 2001 at 10:58:19AM -0800, chris@onca.catsden.net wrote: > > >I seriously doubt he's ON the list. Just your stock standard spam, we need > > >to turn on 'member posting only' :) > > > > Amazingly, he actually was subscribed to the list. I've removed the > > original poster and enabled 'member posting only', but I suspect it'll > > get annoying and be turned off again before too long. For example, > > your post had to be manually approved for some reason. > > See my previous post about member posting. That is a *really* bad idea for > this list. Way way bad. Dito. I've seen spammers sign up on mailing lists too recently -- they seem to have found out how to do this programmatically. In the end the "member posting only" doesn't gain you anything except a lot of moderator trouble due to the additional load of having to accept all non-member mail. A much better idea would be to add more spam protection to the Mailman installation at python.org, so that messages from non-members which have a high spam level are first passed to the moderator for approval *before* going to the list. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Tue Nov 6 13:42:18 2001 From: akuchlin@mems-exchange.org (akuchlin@mems-exchange.org) Date: Tue, 6 Nov 2001 08:42:18 -0500 Subject: [DB-SIG] List spam In-Reply-To: <3BE7A2BE.90407566@lemburg.com>; from mal@lemburg.com on Tue, Nov 06, 2001 at 09:43:42AM +0100 References: <2292DBED5A978A498EABCCE95524499E0281D7F2@osi-postal.osi.ad.ea.com> <20011105145416.K16599@ute.mems-exchange.org> <20011105232607.C17149@lyra.org> <3BE7A2BE.90407566@lemburg.com> Message-ID: <20011106084218.B14500@mems-exchange.org> On Tue, Nov 06, 2001 at 09:43:42AM +0100, M.-A. Lemburg wrote: >I've seen spammers sign up on mailing lists too recently -- they >seem to have found out how to do this programmatically. In the end Uh oh... I've requested notifications of all subscribes/unsubscribes be sent to my mailbox, so I can keep an eye on any suspicious new members. >A much better idea would be to add more spam protection to the >Mailman installation at python.org, so that messages from non-members >which have a high spam level are first passed to the moderator >for approval *before* going to the list. What does "high spam level" mean? Messages to the list aren't likely to be sent through an open relay or directly from a dialup, so those features can't be used for spam detection. Every member's first post could require moderation, but that would require code changes to Mailman. (Maybe this isn't a serious problem. Spammers live on volume, trying to reach as many addresses as possible. Waiting to receive a confirmation, responding to it, and then spamming the list will bring the speed way down, so maybe this more elaborate deception will remain uncommon because it's uneconomical.) Anyway, I don't intend to leave the list in members-only mode for more than a few days or a week. --amk From merk@pacificnet.net Tue Nov 6 14:03:08 2001 From: merk@pacificnet.net (Ian) Date: Tue, 06 Nov 2001 06:03:08 -0800 Subject: [DB-SIG] List spam In-Reply-To: <20011106084218.B14500@mems-exchange.org> References: <3BE7A2BE.90407566@lemburg.com> <2292DBED5A978A498EABCCE95524499E0281D7F2@osi-postal.osi.ad.ea.com> <20011105145416.K16599@ute.mems-exchange.org> <20011105232607.C17149@lyra.org> <3BE7A2BE.90407566@lemburg.com> Message-ID: <5.1.0.14.0.20011106060157.015e88c8@popserver2.pacificnet.net> Ironic that there was one piece of spam on the list, but look how long this thread has become discussing it ;)p At 08:42 AM 11/6/2001 -0500, you wrote: >On Tue, Nov 06, 2001 at 09:43:42AM +0100, M.-A. Lemburg wrote: > >I've seen spammers sign up on mailing lists too recently -- they > >seem to have found out how to do this programmatically. In the end > >Uh oh... I've requested notifications of all subscribes/unsubscribes >be sent to my mailbox, so I can keep an eye on any suspicious new >members. > > >A much better idea would be to add more spam protection to the > >Mailman installation at python.org, so that messages from non-members > >which have a high spam level are first passed to the moderator > >for approval *before* going to the list. > >What does "high spam level" mean? Messages to the list aren't likely >to be sent through an open relay or directly from a dialup, so those >features can't be used for spam detection. Every member's first post >could require moderation, but that would require code changes to >Mailman. From mal@lemburg.com Tue Nov 6 14:38:49 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 06 Nov 2001 15:38:49 +0100 Subject: [DB-SIG] List spam References: <2292DBED5A978A498EABCCE95524499E0281D7F2@osi-postal.osi.ad.ea.com> <20011105145416.K16599@ute.mems-exchange.org> <20011105232607.C17149@lyra.org> <3BE7A2BE.90407566@lemburg.com> <20011106084218.B14500@mems-exchange.org> Message-ID: <3BE7F5F9.425B7C00@lemburg.com> This has nothing to do with databases, just want to get this last message out; hope you don't mind... akuchlin@mems-exchange.org wrote: > > >A much better idea would be to add more spam protection to the > >Mailman installation at python.org, so that messages from non-members > >which have a high spam level are first passed to the moderator > >for approval *before* going to the list. > > What does "high spam level" mean? We discussed this on python-dev I think: spam level is a way to measure the probability with which a message probably contains (non-Python) spam. The technique to define this level usually involves a few word filters and some headers checking with the results mangled into a percentage. The percentage is then calculated for each message handled by the mail system and ones with a high level (e.g. 95%) are held for moderator approval. Should be simple to add to Mailman and thus all python.org based mailing lists. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From kjcole@gri.gallaudet.edu Tue Nov 6 15:36:42 2001 From: kjcole@gri.gallaudet.edu (Kevin Cole) Date: Tue, 6 Nov 2001 10:36:42 -0500 (EST) Subject: [DB-SIG] List spam In-Reply-To: <20011106084218.B14500@mems-exchange.org> Message-ID: Is Mailman's restriction in place regarding the number of folks on the To: and CC: lines? (Two or three would seem like a good number.) I know it ain't much, and I assume it's a given, but it doesn't hurt to ask. On Tue, 6 Nov 2001 akuchlin@mems-exchange.org wrote: > On Tue, Nov 06, 2001 at 09:43:42AM +0100, M.-A. Lemburg wrote: > >I've seen spammers sign up on mailing lists too recently -- they > >seem to have found out how to do this programmatically. In the end > > Uh oh... I've requested notifications of all subscribes/unsubscribes > be sent to my mailbox, so I can keep an eye on any suspicious new > members. > > >A much better idea would be to add more spam protection to the > >Mailman installation at python.org, so that messages from non-members > >which have a high spam level are first passed to the moderator > >for approval *before* going to the list. > > What does "high spam level" mean? Messages to the list aren't likely > to be sent through an open relay or directly from a dialup, so those > features can't be used for spam detection. Every member's first post > could require moderation, but that would require code changes to > Mailman. > > (Maybe this isn't a serious problem. Spammers live on volume, > trying to reach as many addresses as possible. Waiting to receive a > confirmation, responding to it, and then spamming the list will bring > the speed way down, so maybe this more elaborate deception will remain > uncommon because it's uneconomical.) > > Anyway, I don't intend to leave the list in members-only mode for more > than a few days or a week. > > --amk > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > -- Kevin Cole, RHCE, Linux Admin | E-mail: kjcole@gri.gallaudet.edu Gallaudet Research Institute | WWW: http://gri.gallaudet.edu/~kjcole/ Hall Memorial Bldg S-419 | Voice: (202) 651-5135 Washington, D.C. 20002-3695 | FAX: (202) 651-5746 From teg@redhat.com Tue Nov 6 15:57:25 2001 From: teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) Date: 06 Nov 2001 10:57:25 -0500 Subject: [DB-SIG] Feel better, Look better, loose weight, build muscle , and make Money! In-Reply-To: <20011105232530.B17149@lyra.org> References: <2292DBED5A978A498EABCCE95524499E0281D7F2@osi-postal.osi.ad.ea.com> <20011105232530.B17149@lyra.org> Message-ID: Greg Stein writes: > On Mon, Nov 05, 2001 at 10:58:19AM -0800, chris@onca.catsden.net wrote: > > On Mon, 5 Nov 2001, Keating, Tim wrote: > >=20 > > > Could someone please boot this jackass off the list? Thank you. > >=20 > > I seriously doubt he's ON the list. Just your stock standard spam, we= need=20 > > to turn on 'member posting only' :) >=20 > That smiley makes me doubt you were serious, but to clarify: >=20 > 'member posting only' is *off* because we want random non-subscribe= d > users to be able to post here for help. Throwing the hurdle of > subscribing to the list will just get in their way. Mailman can be set to have these messages be approved/discarded by admin - works great. --=20 Trond Eivind Glomsr=F8d Red Hat, Inc. From TKeating@origin.ea.com Tue Nov 6 16:13:14 2001 From: TKeating@origin.ea.com (Keating, Tim) Date: Tue, 6 Nov 2001 10:13:14 -0600 Subject: [DB-SIG] List spam Message-ID: <2292DBED5A978A498EABCCE95524499E0281D7F9@osi-postal.osi.ad.ea.com> Humorous followup: the guy actually had the audacity to email me directly and complain that I was being mean. Much as I find getting spammed by a small, targeted mailing list incredibly annoying, I do see your point about novice Python DB programmers (which I myself was, not too long ago) having a place to go to ask questions without subscribing. TK > -----Original Message----- > From: akuchlin@mems-exchange.org [mailto:akuchlin@mems-exchange.org] > Sent: Tuesday, November 06, 2001 7:42 AM > To: db-sig@python.org > Subject: Re: [DB-SIG] List spam > > Anyway, I don't intend to leave the list in members-only mode for more > than a few days or a week. From paul@dubois.ws Tue Nov 6 17:57:57 2001 From: paul@dubois.ws (Paul DuBois) Date: Tue, 6 Nov 2001 11:57:57 -0600 Subject: [DB-SIG] List spam In-Reply-To: <2292DBED5A978A498EABCCE95524499E0281D7F9@osi-postal.osi.ad.ea.com> References: <2292DBED5A978A498EABCCE95524499E0281D7F9@osi-postal.osi.ad.ea.com> Message-ID: I'm so glad we haven't succumbed to the temptation to keep discussing spam on the list and make the resulting volume of messages much worse than the original spam. :-) From db3l@fitlinxx.com Tue Nov 6 18:09:13 2001 From: db3l@fitlinxx.com (David Bolen) Date: Tue, 6 Nov 2001 13:09:13 -0500 Subject: [DB-SIG] Python database API 2.0/returning Column names with data Message-ID: Greg Stein [gstein@lyra.org] writes: > However, unlike dtuple.py, you end up scanning the *entire* list of records, > creating a dictionary for every row, and then appending that to a list > (which may have to be resized multiple times). > > When I wrote dtuple umpteen million years ago, I had approached the problem > similarly to what you did above. In real life scenarios, it just blew. > Profiling the code showed the bottleneck was that loop. So dtuple was built > to have O(1) for creation, and defer the costly work to access time. And > even then, it doesn't create objects -- it just looks them up. Oh agreed. Thus my plug for dtuple (which I do use, and appreciate :-)). But I think the sample code at least was a simple way to describe how you could produce the structure the request wanted as a way to highlighting the parts of the API (e.g., cursor.description) you would use. At least in my cases, with small to medium data sets, this approach hasn't been a bottleneck but obviously mileage may vary. > There are a million choices in implementation. Various tradeoffs in space > and time, selections of algorithms, etc. Yep, as this very thread highlights :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ From paul@dubois.ws Thu Nov 8 15:49:37 2001 From: paul@dubois.ws (Paul DuBois) Date: Thu, 8 Nov 2001 09:49:37 -0600 Subject: [DB-SIG] DB-API based web session manager - is there one? Message-ID: I'm looking for a web session manager for Python applications that allows session information to be stored in a database (preferably through DB-API). Perhaps it's just me, but I'm coming up empty. Does anyone have a suggestion where I might find such a thing? Thanks. From Anthony Baxter Sun Nov 11 23:29:08 2001 From: Anthony Baxter (Anthony Baxter) Date: Mon, 12 Nov 2001 10:29:08 +1100 Subject: [DB-SIG] DB-API based web session manager - is there one? In-Reply-To: Message from Paul DuBois of "Thu, 08 Nov 2001 09:49:37 MDT." Message-ID: <200111112329.fABNT8S16643@mbuna.arbhome.com.au> If you're using Zope, my SQLSession product does this. Anthony >>> Paul DuBois wrote > I'm looking for a web session manager for Python applications > that allows session information to be stored in a database > (preferably through DB-API). Perhaps it's just me, but I'm > coming up empty. Does anyone have a suggestion where I might > find such a thing? Thanks. > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > -- Anthony Baxter It's never too late to have a happy childhood. From paul@boddie.net Mon Nov 12 17:21:19 2001 From: paul@boddie.net (paul@boddie.net) Date: 12 Nov 2001 17:21:19 -0000 Subject: [DB-SIG] DB-API based web session manager - is there one? Message-ID: <20011112172119.22255.qmail@www2.nameplanet.com> Anthony Baxter wrote: > >If you're using Zope, my SQLSession product does this. I saw this reference for an SQL-based session store for Webware: http://www1.ics.uci.edu/~tshumway/webware/sessionsqlstore.html There was some discussion about session support in Webware fairly recently on the mailing list. Take a look at the Webware site for more details: http://webware.sf.net Paul -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su From bkline@rksystems.com Wed Nov 14 12:23:03 2001 From: bkline@rksystems.com (Bob Kline) Date: Wed, 14 Nov 2001 07:23:03 -0500 (EST) Subject: [DB-SIG] Sybase module Message-ID: Anyone know where Dave Cole's Sybase module has moved? The links to object-craft.com.au appear to be dead. Thanks. -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com From MTuttle@glhec.org Tue Nov 13 15:27:32 2001 From: MTuttle@glhec.org (Tuttle, Mark) Date: Tue, 13 Nov 2001 09:27:32 -0600 Subject: [DB-SIG] examples of edit screens interfacing with Oracle DB Message-ID: <836E12E1B280D21196FD0000F6B985F506F4ABE2@glsxchma1.glhec.org> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C16C57.B68AAA60 Content-Type: text/plain; charset="iso-8859-1" Hello, I am trying to get examples of code that creates an edit screen of Oracle data. Any ideas? Thanks Mark x1476 <> ------_=_NextPart_000_01C16C57.B68AAA60 Content-Type: application/octet-stream; name="Tuttle, Mark.vcf" Content-Disposition: attachment; filename="Tuttle, Mark.vcf" BEGIN:VCARD VERSION:2.1 N:Tuttle;Mark FN:Tuttle, Mark ORG:Great Lakes;Special Projects & Technologies TEL;WORK;VOICE:(608) 246-1476 TEL;WORK;VOICE:(608) 246-1476 TEL;CELL;VOICE:(608) 298-0093 TEL;PAGER;VOICE:(608) 657-0149 ADR;WORK:;*;2401 International Lane;Madison;Wisconsin;53704;United States LABEL;WORK;ENCODING=QUOTED-PRINTABLE:*=0D=0A2401 International Lane=0D=0AMadison, Wisconsin 53704=0D=0AUnited Sta= tes EMAIL;PREF;INTERNET:MTuttle@glhec.org REV:19991105T220822Z END:VCARD ------_=_NextPart_000_01C16C57.B68AAA60-- From fog@debian.org Wed Nov 14 01:20:08 2001 From: fog@debian.org (Federico Di Gregorio) Date: 14 Nov 2001 02:20:08 +0100 Subject: [DB-SIG] psycopg 1.0 Message-ID: <1005700808.560.8.camel@nenya> --=-9XTaXJ5AVEWF25TeBf19 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable hi *, i don't usually send announces of psycopg releases to this list, but this one... well, is 1.0 after all. i'll have some more time in the future and i hope to follow shortly with the announce of the dbapi test suite; i am moving that project out of psycopg and switch to use the default python test classes (too late now to remember the name.) anyway, if anybody is interested just drop me a note. and now... hi everybody and welcome to psycopg 1.0, after eight months of work Michele and Federico are pleased to release the 1.0 version of the psycopg Python/PostgreSQL/Zope database driver. previous releases (especially the 0.99.x series) were already stable for a lot of people but only now, after plugging every memleak, after fixing every segfault, after scratching every itch, psycopg is absolutely ready for the one-dot-oh release. applause, please... :) psycopg can be downloaded from: http://initd.org/Software/psycopg/ have fun, federico what you get with psycopg 1.0 ----------------------------- * very fast python/posgresql database driver, optimized for heavy multithreaded applications (very fast means that several people have=20 reported many-fold speedups when switching to psycopg, and in real=20 world situations, not benchmarks); * stability. a lot of people have run with it for weeks without a single problem. unplug the database or kill the connection, psycopg will just raise an exception, rollback and go back to work. * complete (and we mean 100% complete) DBAPI 2.0 compliance; * DBAPI extensions: per-cursor commits, isolated cursors, user-defined typecast objects (postgresql->python), lastoid() function and other goodies; * complete translation of postgresql date, time, timestamp and interval types to eGenix (http://www.egenix.com/) mx DateTime and=20 DateTimeDelta objects. * Zope database adapter (ZpsycopgDA); * stability (have I already said that?) what is missing from 1.0 ------------------------ * documentation: we are working on two guides, one about DBAPI 2.0 programming and one about psycopg itself. both will be released in a future psycopg release. * regression test: much needed to be sure the development branch does not remove features or introduce new bugs. * how zpsycopgda should treat intervals is still dubious. until we make a decision you'll get strings if using Zope's DatTime or DateTimeDelta objects if using mx's. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org 99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me --=-9XTaXJ5AVEWF25TeBf19 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjvxxsgACgkQvcCgrgZGjeu+kQCg0J0EVNquXBHAEthMrj8U5+ts FNkAoJWyWxfHpVc/YDVQDgiFKYn9lLAs =PU2K -----END PGP SIGNATURE----- --=-9XTaXJ5AVEWF25TeBf19-- From andy47@halfcooked.com Wed Nov 14 23:02:22 2001 From: andy47@halfcooked.com (Andy Todd) Date: Thu, 15 Nov 2001 10:02:22 +1100 Subject: [DB-SIG] examples of edit screens interfacing with Oracle DB References: <836E12E1B280D21196FD0000F6B985F506F4ABE2@glsxchma1.glhec.org> Message-ID: <3BF2F7FE.8080609@halfcooked.com> Mark, Tuttle, Mark wrote: > Hello, > I am trying to get examples of code that creates an edit screen of Oracle > data. Any ideas? I'm not entirely sure of what you want here, but if you are talking about application code that interfaces with data in an Oracle database then there are plenty of examples in the c.l.p. archives on google. You can also look at the dbBrowser sample application with PythonCard (http://pythoncard.sourceforge.net/) which in the current CVS version allows you to browse data in an Oracle database. It shows how to query the data dictionary as well as end user tables to dynamically construct representations of rows in the PythonCard environment. > > Thanks > Mark > x1476 > <> > Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Another year older, still no wiser." - Me, on my birthday From kimtitu@yahoo.com Thu Nov 15 07:39:08 2001 From: kimtitu@yahoo.com (Titu Kim) Date: Wed, 14 Nov 2001 23:39:08 -0800 (PST) Subject: [DB-SIG] Result from DCOracle2 different from sqlplus Message-ID: <20011115073908.89045.qmail@web14704.mail.yahoo.com> Hi, I am confused when retrieve data from database using same query. For instance, my query is "SELECT emp_id FROM EMPLOYEE" and data type of emp_id is NUMBER. If i execute this query using DCOracle2 in python, i get id number with 1 decimal number like, [[1.0],[14.0]]. However, if i run the same query in sqlplus, i get the same result without any decimal point. Why can this happen? Any idea? Regards, Kim Titu __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From magnus@thinkware.se Thu Nov 15 11:21:09 2001 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Thu, 15 Nov 2001 12:21:09 +0100 Subject: [DB-SIG] Result from DCOracle2 different from sqlplus In-Reply-To: <20011115073908.89045.qmail@web14704.mail.yahoo.com> Message-ID: <5.1.0.14.0.20011115102403.02517b60@localhost> At 23:39 2001-11-14 -0800, Kim Titu wrote: >Hi, > I am confused when retrieve data from database using >same query. For instance, my query is "SELECT emp_id >FROM EMPLOYEE" and data type of emp_id is NUMBER. If i >execute this query using DCOracle2 in python, i get id >number with 1 decimal number like, [[1.0],[14.0]]. >However, if i run the same query in sqlplus, i get the >same result without any decimal point. Why can this >happen? Any idea? Python has four numeric types: integer, long, float and complex. I think we can skip complex for now though. Long and integer can't display any fractions, just whole numbers. Long can hold any size of whole number, but integer is limited by the CPU, for instance to 32 bits. Float can handle fractions and very large and small numbers, but only with a limited precision. They are stored in the computer in a binary format called IEEE 754 double precision. See for instance http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html (To be picky, they use the C type double of the C compiler used to compile Python, but they typically use this standard.) These numbers can span a large range of values, but they can't store all decimal values exactly. For example: >>> x =3D 0.6 >>> x 0.59999999999999998 but >>> print x 0.6 (Python is rounding a bit here.) Oracle's NUMBER is another beast. It's not a floating point number, but rather a fixed point number where you can define a range for its size. This means that you can use it for fractions, but still know the exact value. So, while Python gives you a choice between exact integers or inexact numbers with fractions, you can actually get both in Oracle's NUMBER type. Since the NUMBER type *can* hold fractions, there is in the general case no choice but to map it to float in Python. Python displays all floats with at least one decimal, regardless of their values. Otherwise you wouldn't be able to see if it was a float or an integer. >>> print float(1) 1.0 Of course, in many cases NUMBER values could be mapped to Python integer or long, but this depends on their values. It would be stupid to implement a DB-API so that you never know what type to expect from a NUMBER column in a database. Right? But NUMBER takes two arguments, precision and scale. For instance NUMBER(5,2) can store the values: -999.99, -999.98 ... +999.98, +999.99. Just typing NUMBER(5) is short for NUMBER(5,0), and just typing NUMBER is short for NUMBER(38). (At least in Oracle 7). For instance NUMBER(9,0), could be mapped to integer, but NUMBER(10,0) would need to be mapped to long, and of course NUMBER(5,2) would need to be a float. DCOracle takes the more convenient path and maps all NUMBER to float. If you want integers, you can use the INTEGER data type in your SQL. This is also a safe choice. I don't know how Oracle NUMBER is implemented, but the SQL standard data type DECIMAL does actually allow the database to store more than the declaration of the data type suggests. For instance it is legal for a database to allow a larger value than 9.9 to be stored in a field declared as DECIMAL(2,1), but it is illegal if it's declared as NUMERIC(2,1). If Oracle's NUMBER behaves like SQL DECIMAL, mapping NUMBER(9) to integer might lead to overflows. Please note that NUMBER is not an SQL type, but an Oracle proprietary type. If you have a recent enough Oracle I would suggest that you use one of the standard SQL numeric data types. (I know Oracle 7 didn't have any other numeric type.) In your case I imagine the employee ID is really an INTEGER. There is really no reason to use a datatype allowing for fractions and values larger than 2147483647 to use number like 1 and 14. It could actually be practical with a fixed point decimal data type or standard class in Python. These kinds of values are common in relational databases and for instance in administrative systems. I think COBOL has such a data type. Unfortunately, this does not exist in Python or in the DB-API standard. Understanding the limitations of various numeric types and the consequences of using them is important for programmers. Particularly the lack of precision in floats. For instance, you should never compare floats for equality, but rather use something like: def equal(a,b,fuzzFactor): if a-fuzzFactor < b < a+fuzzFactor: return 1 else: return 0 -- Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From matt@zope.com Thu Nov 15 13:35:32 2001 From: matt@zope.com (Matthew T. Kromer) Date: Thu, 15 Nov 2001 08:35:32 -0500 Subject: [DB-SIG] Result from DCOracle2 different from sqlplus References: <20011115073908.89045.qmail@web14704.mail.yahoo.com> Message-ID: <3BF3C4A4.4050300@zope.com> Titu Kim wrote: >Hi, > I am confused when retrieve data from database using >same query. For instance, my query is "SELECT emp_id >FROM EMPLOYEE" and data type of emp_id is NUMBER. If i >execute this query using DCOracle2 in python, i get id >number with 1 decimal number like, [[1.0],[14.0]]. >However, if i run the same query in sqlplus, i get the >same result without any decimal point. Why can this >happen? Any idea? > >Regards, >Kim Titu > Hi Kim, DCOracle2 takes a look at the scale and precision of the number -- by default, NUMBERs with no scale or precision (which sometimes Oracle represents internally as maximum precision) can contain both floating point values and integers. When converting a column to a python type, DCOracle2 doesn't want to have two different result types in the same column, so if the column COULD contain a floating point, the whole column is represented as floating point. To force the column type to be integer only, you can declare it as NUMBER(9) -- anything larger than this would indicate the possibility of a Long integer being returned. From paul@boddie.net Fri Nov 16 09:07:11 2001 From: paul@boddie.net (paul@boddie.net) Date: 16 Nov 2001 09:07:11 -0000 Subject: [DB-SIG] Result from DCOracle2 different from sqlplus Message-ID: <20011116090711.14179.qmail@www2.nameplanet.com> wrote: > >It could actually be practical with a fixed point decimal data >type or standard class in Python. These kinds of values are common >in relational databases and for instance in administrative systems. >I think COBOL has such a data type. Unfortunately, this does not >exist in Python or in the DB-API standard. I wrote a simple implementation of a fixed point class for my XMLForms project; see http://www.paul.boddie.net for details. The class is called ScaledDecimal and is described in some detail in the documentation, which can be found here: http://www.paul.boddie.net/Python/XMLForms/applications.html (See the "Element Type Mappings" table and the text below it.) It isn't exactly sophisticated, but it does a lot more than the implementation that was floating around as part of one of the numeric PEPs. Paul -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su From mal@lemburg.com Fri Nov 16 09:46:12 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 16 Nov 2001 10:46:12 +0100 Subject: [DB-SIG] Fixed point numbers (Result from DCOracle2 different from sqlplus) References: <20011116090711.14179.qmail@www2.nameplanet.com> Message-ID: <3BF4E064.19DFA9BE@lemburg.com> paul@boddie.net wrote: > > wrote: > > > >It could actually be practical with a fixed point decimal data > >type or standard class in Python. These kinds of values are common > >in relational databases and for instance in administrative systems. > >I think COBOL has such a data type. Unfortunately, this does not > >exist in Python or in the DB-API standard. > > I wrote a simple implementation of a fixed point class for my XMLForms project; > see http://www.paul.boddie.net for details. The class is called ScaledDecimal > and is described in some detail in the documentation, which can be found here: > > http://www.paul.boddie.net/Python/XMLForms/applications.html > (See the "Element Type Mappings" table and the text below it.) > > It isn't exactly sophisticated, but it does a lot more than the implementation > that was floating around as part of one of the numeric PEPs. How strong is the need for a fixed point data type ? I'm asking because I originally started the mxNumber project to eventually come up with an implementation for rational numbers or fixed point numbers. The rational number is there (it basically wraps the GNU MP rational data type and thus is reasonably fast), the fixed point number type is still missing -- mostly because I'm not sure how to handle rounding/truncation "right" (in some sense of the word "right"). Does anyone have pointers as to which logic is the most common ? Note that a fixed point type wouldn't be hard to do with Python's long implementation: you'd just have to keep an additional integer around which then defines the location of the decimal point. Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From paul@boddie.net Fri Nov 16 12:21:41 2001 From: paul@boddie.net (paul@boddie.net) Date: 16 Nov 2001 12:21:41 -0000 Subject: [DB-SIG] Fixed point numbers (Result from DCOracle2 different from sqlplus) Message-ID: <20011116122141.5144.qmail@www2.nameplanet.com> On Fri, 16 Nov 2001 10:46:12 +0100 "M.-A. Lemburg" wrote: > >How strong is the need for a fixed point data type ? For convenient handling of financial information, I would claim that it's a very strong need. It's ironic that in the PEP 238 discussions and other debates around the implementation of Python's numerics which even got into referring to Visual Basic's currency type, if I remember correctly, no-one really addressed the needs of applications like these, although some people may have mentioned the dangers of floating point numbers in financial applications. >I'm asking because I originally started the mxNumber project to >eventually come up with an implementation for rational numbers >or fixed point numbers. The rational number is there (it basically >wraps the GNU MP rational data type and thus is reasonably >fast), the fixed point number type is still missing -- mostly >because I'm not sure how to handle rounding/truncation "right" >(in some sense of the word "right"). > >Does anyone have pointers as to which logic is the most >common ? Well, as you can see in the documentation that I referred to in my previous message, the way that integers behave when implicitly rounded (in division) is surprising, if not shocking, and any justification for it should really lead to calling the Python integer type something else like "index". What I did in my implementation is to follow commonly-believed basic arithmetic conventions; so, for the ScaledDecimal class any rounding is done towards zero, whereas for Python integer arithmetic such rounding is done towards minus infinity. Operations involving ScaledDecimal objects tend to extend the precision until such a time as either rounding or conversion to integer is done. The reason for deferring rounding or truncation is that it isn't always clear that such things are wanted by the programmer; I suppose one could have an option which truncates or rounds after every operation - it would be the equivalent of "autocommit" for numbers. ;-) >Note that a fixed point type wouldn't be hard to do with >Python's long implementation: you'd just have to keep an >additional integer around which then defines the location >of the decimal point. That's pretty much what I do, yes. Regards, Paul -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su From magnus@thinkware.se Fri Nov 16 13:45:39 2001 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Fri, 16 Nov 2001 14:45:39 +0100 Subject: [DB-SIG] Fixed point numbers (Result from DCOracle2 different from sqlplus) In-Reply-To: <3BF4E064.19DFA9BE@lemburg.com> References: <20011116090711.14179.qmail@www2.nameplanet.com> Message-ID: <5.1.0.14.0.20011116120241.02570250@localhost> At 10:46 2001-11-16 +0100, M.-A. Lemburg wrote: >How strong is the need for a fixed point data type ? Maybe I should say something since I raised the issue... I don't have a strong need right now. When I've been cursing my commercial accounting software for its stupidity (and no other package I've seen seem to address the basic flaws), I've often thought that I should do something better in Python, or at least a front end so that I can work more conveniently. If I ever get irritated enough to actually do that, I would probably need some kind of money class. As M.-A. pointed out, this is easily sovled with a long and an int. Although, using a rational numbers class is also a solution. With a Rational(n,d) class I could imagine something like... class Money: def __init__(self, whole, fraction, currency): self.__currency =3D Currency(currency) denominator =3D self.__currency.centSize # Usually 100 self.__value(Rational(whole*denominator+fraction,denominator)) def __add__(self, other): assert self.__currency =3D=3D other.__currency val =3D self.__value + other.__value whole, frac =3D val.divmod() return Money(whole, frac, self.__currency) ... I guess I'd use the following for a few more years... class SEK(Money): def __init__(self, kr, ore): Money.__init__(self,kr,ore,'SEK') Actually, I have a backlog of book keeping. Maybe this could be a way do make all that boring book keeping fun! From the db-sig point of view, a fixed point numbers class would certainly provide a better match to the databases, since they all provide this type. Then we just need to get a DateTime package and support for bit strings into the standard library and we're all set! Right? (Well, I don't know how compatible we are with SQL in National Character handling...) I guess good support for bit (strings) should be: >>> 0b101 5 >>> "%b" % 5 '101' Considering the discussion of Python for learning programming and the importance of binary nubers in actually understanding how computers work, I think this is an oversight. At least we have >>> int('101',2) 5 But going back to the subject: Floating point arithmetic makes sense for engineering and scientific computations. For areas like business administration they don't. It's no accident that both COBOL and relational databases that are often used for business administration etc, support fixed point numbers. If Python is (as I gather) intended for a wide audience, and supposed to be useful also for people who are not professional programmers, I think support for fixed point arithmetic would be a Good Thing. -- Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From djc@object-craft.com.au Sat Nov 17 07:39:02 2001 From: djc@object-craft.com.au (Dave Cole) Date: 17 Nov 2001 18:39:02 +1100 Subject: [DB-SIG] Sybase module In-Reply-To: References: Message-ID: >>>>> "Bob" == Bob Kline writes: Bob> Anyone know where Dave Cole's Sybase module has moved? The links Bob> to object-craft.com.au appear to be dead. Thanks. It should be working again. Our Telco cut off our communications for the fourth time in a year... - Dave From fog@debian.org Mon Nov 19 20:16:20 2001 From: fog@debian.org (Federico Di Gregorio) Date: 19 Nov 2001 21:16:20 +0100 Subject: [DB-SIG] Re: zope, zope-popyda, psycopg and python1.5-{,egenix-}mxdatetime In-Reply-To: <20011119151035.U6966@universal-fasteners.com> References: <87bshy4jqq.fsf@n114.ryd.student.liu.se> <1006200254.603.10.camel@nenya> <20011119151035.U6966@universal-fasteners.com> Message-ID: <1006200980.603.14.camel@nenya> --=-ZCrzVBzwtbWEMdf1B9O9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 2001-11-19 at 21:10, Jim Penny wrote: > On Mon, Nov 19, 2001 at 09:04:14PM +0100, Federico Di Gregorio wrote: > > On Mon, 2001-11-19 at 20:57, Joel Rosdahl wrote: > > > Good evening, > > >=20 > > > Does anyone have opinions on this? Is there a need for a > > > python1.5-mxdatetime (based on the old mxdatetime) or a > > > python1.5-egenix-mxdatetime (based on the new egenix mxdatetime)? > >=20 > > psycopg currently in incoming has versions with the following > > dependencies: > >=20 > > python-psycopg: python2.1-psycopg, python (>=3D 2.1), python (<< 2.2) > > python2.1-psycopg: python2.1-egenix-mxdatetime, python2.1 > > python1.5-psycopg: python-egenix-mxdatetime, python1.5 > > zope-psycopgda: zope, python2.1-psycopg >=20 > Huh? >=20 > Package: python-egenix-mxdatetime > Source: egenix-mx-base > Version: 2.0.2-5 > Depends: python (>=3D 2.1), python (<< 2.2), python2.1-egenix-mxdatetime ouch! lemmesee... same here. mmm... the question is... how was i able to build that package? =20 yes, we need a python1.5-egenix-mxdatetime package, i think. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org La felicit=E0 =E8 una tazza di cioccolata calda. Sempre. -- I= o --=-ZCrzVBzwtbWEMdf1B9O9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjv5aJQACgkQvcCgrgZGjetSIgCePGlF7MxUBR1ygXkHUtOajOZr trIAoMZKGcpZpUPJ6F8NYZC+5wRy6R0V =X2FC -----END PGP SIGNATURE----- --=-ZCrzVBzwtbWEMdf1B9O9-- From mal@lemburg.com Tue Nov 20 09:40:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 20 Nov 2001 10:40:00 +0100 Subject: [DB-SIG] Re: zope, zope-popyda, psycopg and python1.5-{,egenix-}mxdatetime References: <87bshy4jqq.fsf@n114.ryd.student.liu.se> <1006200254.603.10.camel@nenya> <20011119151035.U6966@universal-fasteners.com> <1006200980.603.14.camel@nenya> Message-ID: <3BFA24F0.B719557C@lemburg.com> Federico Di Gregorio wrote: > > On Mon, 2001-11-19 at 21:10, Jim Penny wrote: > > On Mon, Nov 19, 2001 at 09:04:14PM +0100, Federico Di Gregorio wrote: > > > On Mon, 2001-11-19 at 20:57, Joel Rosdahl wrote: > > > > Good evening, > > > > > > > > Does anyone have opinions on this? Is there a need for a > > > > python1.5-mxdatetime (based on the old mxdatetime) or a > > > > python1.5-egenix-mxdatetime (based on the new egenix mxdatetime)? > > > > > > psycopg currently in incoming has versions with the following > > > dependencies: > > > > > > python-psycopg: python2.1-psycopg, python (>= 2.1), python (<< 2.2) > > > python2.1-psycopg: python2.1-egenix-mxdatetime, python2.1 > > > python1.5-psycopg: python-egenix-mxdatetime, python1.5 > > > zope-psycopgda: zope, python2.1-psycopg > > > > Huh? > > > > Package: python-egenix-mxdatetime > > Source: egenix-mx-base > > Version: 2.0.2-5 > > Depends: python (>= 2.1), python (<< 2.2), python2.1-egenix-mxdatetime > > ouch! lemmesee... same here. mmm... the question is... how was i able to > build that package? > > yes, we need a python1.5-egenix-mxdatetime package, i think. Uhm, why don't you just use the standard egenix-mx-base package which comes for Python 1.5.2, 2.0 and 2.1 instead of creating a new RPM distribution ? Note that the base package will sooner or later grow intra- package dependencies (which is why I wrapped them up as single distribution package), so ripping out just the mxDateTime part could fail at some point in the future. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From fog@mixadlive.com Tue Nov 20 10:16:35 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: 20 Nov 2001 11:16:35 +0100 Subject: [DB-SIG] Re: zope, zope-popyda, psycopg and python1.5-{,egenix-}mxdatetime In-Reply-To: <3BFA24F0.B719557C@lemburg.com> References: <87bshy4jqq.fsf@n114.ryd.student.liu.se> <1006200254.603.10.camel@nenya> <20011119151035.U6966@universal-fasteners.com> <1006200980.603.14.camel@nenya> <3BFA24F0.B719557C@lemburg.com> Message-ID: <1006251395.566.8.camel@nenya> On Tue, 2001-11-20 at 10:40, M.-A. Lemburg wrote: > > yes, we need a python1.5-egenix-mxdatetime package, i think. > > Uhm, why don't you just use the standard egenix-mx-base > package which comes for Python 1.5.2, 2.0 and 2.1 instead > of creating a new RPM distribution ? because we were talking about a DEB package, not RPM. for some strange reason a mail intended for debian-python ended up in python db-sig ML. > Note that the base package will sooner or later grow intra- > package dependencies (which is why I wrapped them up as > single distribution package), so ripping out just the > mxDateTime part could fail at some point in the future. debian packaging system supports dependencies much better than rpm. we won't have such problems. python-egenix-mxdatetime already depends on python-egenix-base were all the common stuff is kept. sorry for bothering you with arguments not intended for this list, federico -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org God is real. Unless declared integer. -- Anonymous FORTRAN programmer From mal@lemburg.com Thu Nov 22 08:56:14 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 22 Nov 2001 09:56:14 +0100 Subject: [DB-SIG] Re: zope, zope-popyda, psycopg and python1.5-{,egenix-}mxdatetime References: <87bshy4jqq.fsf@n114.ryd.student.liu.se> <1006200254.603.10.camel@nenya> <20011119151035.U6966@universal-fasteners.com> <1006200980.603.14.camel@nenya> <3BFA24F0.B719557C@lemburg.com> <1006251395.566.8.camel@nenya> Message-ID: <3BFCBDAE.5FA2C8D8@lemburg.com> Federico Di Gregorio wrote: > > On Tue, 2001-11-20 at 10:40, M.-A. Lemburg wrote: > > > yes, we need a python1.5-egenix-mxdatetime package, i think. > > > > Uhm, why don't you just use the standard egenix-mx-base > > package which comes for Python 1.5.2, 2.0 and 2.1 instead > > of creating a new RPM distribution ? > > because we were talking about a DEB package, not RPM. for some strange > reason a mail intended for debian-python ended up in python db-sig ML. Ah, ok. Which reminds me: why is there no bdist_deb in distutils ? Perhaps one of the Debian Python packagers could write up such a beast ?! > > Note that the base package will sooner or later grow intra- > > package dependencies (which is why I wrapped them up as > > single distribution package), so ripping out just the > > mxDateTime part could fail at some point in the future. > > debian packaging system supports dependencies much better than rpm. we > won't have such problems. python-egenix-mxdatetime already depends on > python-egenix-base were all the common stuff is kept. Ok.. I still don't see the advantage though, but that must be a Debian thing ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Fri Nov 23 11:29:47 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 23 Nov 2001 12:29:47 +0100 Subject: [DB-SIG] Extensions to DB API 2.0 Message-ID: <3BFE332B.F80A9248@lemburg.com> I would like to integrate the proposed standard extensions to=20 DB API 2.0 into the DB API PEP in the next few days. If you have more comments to make, please speak up now. -- PEP: Addition to PEP 249 Title: Optional Database API Extensions Version: $Revision: 1.2$ Author: mal@lemburg.com (Marc-Andr=E9 Lemburg) Status: Draft Type: Standards Track Python-Version: 2.3 Created: 23-Oct-2001 Post-History:=20 Abstract This pre-PEP should provide a discussion basis for an "Optional Extensions" section in the DB API 2.0 standard PEP 249. Feel free to add/change text as required. Problem Even though the DB API 2.0 standard already provides a multitude of APIs, there are some common situations where a database package writer will want to add features which are specific to the database, but which could also be implemented for other databases as well. This pre-PEP will collect these common extensions for subsequent inclusion in the DB API 2.0 standard. Note that all extensions will be marked "optional", meaning that database writers are free to implement them, but are not required to do so in order to have a DB API 2.0 compatible package. Proposed Common Extensions As with all DB API optional features, the database module authors are free to not implement these additional attributes and methods (using them will then result in an AttributeError), to raise a NotSupportedError in case the availability can only be checked at run-time. It has been proposed to make usage of these extensions optionally visible to the programmer by issuing Python warnings through the Python warning framework. To make this feature useful, the warning messages must be standardized in order to be able to mask them. These standard messages are referred to below as "Warning Message". Cursor Attribute .rownumber This read-only attribute should provide the current 0-based index of the cursor in the result set or -1 if the index cannot be determined. The index can be seen as index of the cursor in a sequence (the result set). The next fetch operation will fetch the row indexed by .rownumber in that sequence. Warning Message: "DB-API extension cursor.rownumber used" Connection Attributes .Error, .ProgrammingError, etc. All exception classes defined by the DB API standard should be exposed on the Connection objects are attributes (in addition to being available at module scope). These attributes simplify error handling in multi-connection environments. Warning Message: "DB-API extension connection. used" Cursor Attributes .connection This read-only attribute return a reference to the Connection object on which the cursor was created. The attribute simplifies writing polymorph code in multi-connection environments. Warning Message: "DB-API extension cursor.connection used" Cursor Method .scroll(value[,mode=3D'relative']) Scroll the cursor in the result set to a new position according to mode. =20 If mode is 'relative' (default), value is taken as offset to the current position in the result set, if set to 'absolute', value states an absolute target position. An IndexError should be raised in case a scroll operation would leave the result set. In this case, the cursor position is left undefined (ideal would be to not move the cursor at all). Note: This method should use native scrollable cursors, if available , or revert to an emulation for forward-only scrollable cursors. The method may raise NotSupportedErrors to signal that a specific operation is not supported by the database (e.g. backward scrolling). Warning Message: "DB-API extension cursor.scroll() used" Cursor Attribute .messages This is a Python list object to which the interface appends tuples (exception class, exception value) for all messages which the interfaces receives from the underlying database for this cursor. The list is cleared by all standard cursor methods calls (prior to executing the call) except for the .fetchXXX() calls automatically to avoid excessive memory usage and can also be cleared by executing "del cursor.messages[:]". All error and warning messages generated by the database are placed into this list, so checking the list allows the user to verify correct operation of the method calls. The aim of this attribute is to eliminate the need for a Warning exception which often causes problems (some warnings really only have informational character). Warning Message: "DB-API extension cursor.messages used" Connection Attribute .messages Same as cursor.messages except that the messages in the list are connection oriented. The list is cleared automatically by all standard connection methods calls (prior to executing the call) to avoid excessive memory usage and can also be cleared by executing "del connection.messages[:]". Warning Message: "DB-API extension connection.messages used" Cursor Method .next() =20 Return the next row from the currently executing SQL statement using the same semantics as .fetchone(). A StopIteration exception is raised when the result set is exhausted for Python versions 2.2 and later. Previous versions don't have the StopIteration exception and so the method should raise an IndexError instead. =20 Warning Message: "DB-API extension cursor.next() used" Cursor Method .__iter__() =20 Return self to make cursors compatible to the iteration protocol. Warning Message: "DB-API extension cursor.__iter__() used" Cursor Attribute .lastrowid This read-only attribute provides the rowid of the last modified row (most databases return a rowid only when a single INSERT operation is performed.) If the operation does not set a rowid or if the database does not support rowids, this attribute should be set to None. The semantics of .lastrowid are undefined in case the last executed statement modified more than one row, e.g. when using INSERT with .executemany(). Warning Message: "DB-API extension cursor.lastrowid used" Proposed Error Handling Extension In order to simplify error handling when dealing with databases, database module authors may choose to implement user defineable error handlers. This section describes a standard way of defining these error handlers. Cursor/Connection Attribute .errorhandler Read/write attribute which references an error handler to call in case an error condition is met.=20 The handler must be a Python callable taking the following arguments: errorhandler(connection, cursor, errorclass, errorvalue) where connection is a reference to the connection on which the cursor operates, cursor a reference to the cursor (or None in case the error does not apply to a cursor), errorclass is an error class which to instantiate using error value as construction arguments. The standard error handler should add the error information to the appropriate .messages attribute (connection.messages or cursor.messages) and raise the exception defined by the given errorclass and errorvalue parameters. If no errorhandler is set (the attribute is None), the standard error handling scheme as outlined above, should be applied. Warning Message: "DB-API extension .errorhandler used" Cursors should inherit the .errorhandler setting from their connection objects. Proposed Informational Extensions A very common question on the DB-SIG mailing list is how to construct a dictionary out of the tuples returned by .fetchxxx(). There are several existing tools available which provide helpers for this task. Most of them use the approach of using the column names defined in the cursor attribute .description as basis for the keys in the row dictionary. Note that the reason for not extending the DB API specification to also support dictionary return values for the .fetchxxx() methods is that this approach has several drawbacks:=20 * Some databases don't support case-sensitive column names or auto-convert them to all lowercase or all uppercase characters. =20 * Columns in the result set which are generated by the query (e.g. using SQL functions) don't map to table column names and databases usually generate names for these columns in a very database specific way. As a result, accessing the columns through dictionary keys varies between databases and makes writing portable code impossible. Scope This PEP only affects database modules/packages which adhere to the Python DB API 2.0 standard. Some of these extensions may become manditory features in future DB API standard versions. Copyright This document has been placed in the public domain. =0C Local Variables: mode: indented-text indent-tabs-mode: nil End: --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From andy@dustman.net Sat Nov 24 03:51:31 2001 From: andy@dustman.net (Andy Dustman) Date: 23 Nov 2001 22:51:31 -0500 Subject: [DB-SIG] Extensions to DB API 2.0 In-Reply-To: <3BFE332B.F80A9248@lemburg.com> References: <3BFE332B.F80A9248@lemburg.com> Message-ID: <1006573891.2012.5.camel@chef.comstar.net> On Fri, 2001-11-23 at 06:29, M.-A. Lemburg wrote: > > Cursor Attribute .rownumber > > This read-only attribute should provide the current 0-based > index of the cursor in the result set or -1 if the index cannot > be determined. Didn't we decide that None was a better choice for this? > Scope > > This PEP only affects database modules/packages which adhere to > the Python DB API 2.0 standard. Some of these extensions may > become manditory features in future DB API standard versions. "Mandatory". -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From mal@lemburg.com Sat Nov 24 14:54:09 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 24 Nov 2001 15:54:09 +0100 Subject: [DB-SIG] Extensions to DB API 2.0 References: <3BFE332B.F80A9248@lemburg.com> <1006573891.2012.5.camel@chef.comstar.net> Message-ID: <3BFFB491.633B8D9D@lemburg.com> Andy Dustman wrote: > > On Fri, 2001-11-23 at 06:29, M.-A. Lemburg wrote: > > > > Cursor Attribute .rownumber > > > > This read-only attribute should provide the current 0-based > > index of the cursor in the result set or -1 if the index cannot > > be determined. > > Didn't we decide that None was a better choice for this? Correct. I must have forgotten to update this part. > > Scope > > > > This PEP only affects database modules/packages which adhere to > > the Python DB API 2.0 standard. Some of these extensions may > > become manditory features in future DB API standard versions. > > "Mandatory". Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ PS: mxODBC 2.1 will support almost all of these extensions except .lastrowid and the warning messages. From andy@dustman.net Sat Nov 24 22:15:27 2001 From: andy@dustman.net (Andy Dustman) Date: 24 Nov 2001 17:15:27 -0500 Subject: [DB-SIG] Extensions to DB API 2.0 In-Reply-To: <3BFFB491.633B8D9D@lemburg.com> References: <3BFE332B.F80A9248@lemburg.com> <1006573891.2012.5.camel@chef.comstar.net> <3BFFB491.633B8D9D@lemburg.com> Message-ID: <1006640127.1428.0.camel@chef.comstar.net> On Sat, 2001-11-24 at 09:54, M.-A. Lemburg wrote: > PS: mxODBC 2.1 will support almost all of these extensions except > .lastrowid and the warning messages. Same (more or less) for MySQLdb-0.9.2 (or 1.0.0, whichever I decide to make it). -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From mal@lemburg.com Mon Nov 26 13:02:07 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 26 Nov 2001 14:02:07 +0100 Subject: [DB-SIG] ANN: eGenix.com mx COMMERCIAL Extension Package 2.0.4 Message-ID: <3C023D4F.23A54FF0@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx COMMERCIAL Extension Package for Python Version 2.0.4 Full Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx COMMERCIAL Package for Python is part of the eGenix.com mx Extension Series for Python, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. This commercial package includes the popular mxODBC extension which allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux. By providing a consistent interface on all supported platforms, mxODBC serves as perfect base for writing cross-platform database programs and utilities. ________________________________________________________________________ WHAT'S NEW ? Compatibility to Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server ODBC drivers was enhanced in mxODBC. It is now possible to exchange native Unicode data with these Unicode-capable databases using mxODBC. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ SPECIAL OFFER theKompany.com has licensed the eGenix.com mx Commercial Package (which includes mxODBC) for inclusion in their brand new Qt-based Python IDE BlackAdder. It allows developing portable GUI-based database applications which run on Windows and Linux platforms without any change to the source code. BlackAdder includes a 1 CPU license for this package at no extra cost, so you may want to check out their great new product. See http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#BlackAdder for details. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.lemburg.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.lemburg.com/files/python/ Note that in order to use the eGenix.com mx COMMERCIAL package you will also need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? mxODBC comes with a licenses which allows non-commercial use at no charge, but places a moderate fee on commercial users. Special licensing setups are available for commercial product developers. Please see http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#mxCOMMERCIAL for details. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ REFERENCE:

eGenix.com mx COMMERCIAL Package 2.0.4 - eGenix.com mx COMMERCIAL Interface 2.0.4 with distutils support and precompiled binaries for Windows and Linux. (26-Nov-2001) ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From fog@debian.org Sat Nov 24 22:54:58 2001 From: fog@debian.org (Federico Di Gregorio) Date: 24 Nov 2001 23:54:58 +0100 Subject: [DB-SIG] Extensions to DB API 2.0 In-Reply-To: <3BFFB491.633B8D9D@lemburg.com> References: <3BFE332B.F80A9248@lemburg.com> <1006573891.2012.5.camel@chef.comstar.net> <3BFFB491.633B8D9D@lemburg.com> Message-ID: <1006642498.602.2.camel@nenya> --=-KibKduSlNCuDj+aYkiS3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2001-11-24 at 15:54, M.-A. Lemburg wrote: > Andy Dustman wrote: > >=20 > > On Fri, 2001-11-23 at 06:29, M.-A. Lemburg wrote: > > > > > > Cursor Attribute .rownumber > > > > > > This read-only attribute should provide the current 0-based > > > index of the cursor in the result set or -1 if the index canno= t > > > be determined. > >=20 > > Didn't we decide that None was a better choice for this? >=20 > Correct. I must have forgotten to update this part. mm.. wasn't None for .lastrowid and -1 for .rownumber? --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Quis custodiet ipsos custodes? -- Juvenal, Satires, VI, 347 --=-KibKduSlNCuDj+aYkiS3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjwAJUIACgkQvcCgrgZGjev4lgCfdgdGET8U1Q5lFG4cSpcpq0Ez wwcAoMLLjKeF2MaGdAFRdG+aIO0HMVmR =p2Ru -----END PGP SIGNATURE----- --=-KibKduSlNCuDj+aYkiS3-- From andy@dustman.net Mon Nov 26 23:15:22 2001 From: andy@dustman.net (Andy Dustman) Date: 26 Nov 2001 18:15:22 -0500 Subject: [DB-SIG] Extensions to DB API 2.0 In-Reply-To: <1006642498.602.2.camel@nenya> References: <3BFE332B.F80A9248@lemburg.com> <1006573891.2012.5.camel@chef.comstar.net> <3BFFB491.633B8D9D@lemburg.com> <1006642498.602.2.camel@nenya> Message-ID: <1006816522.12410.27.camel@chef.comstar.net> On Sat, 2001-11-24 at 17:54, Federico Di Gregorio wrote: > On Sat, 2001-11-24 at 15:54, M.-A. Lemburg wrote: > > Andy Dustman wrote: > > > > > > On Fri, 2001-11-23 at 06:29, M.-A. Lemburg wrote: > > > > > > > > Cursor Attribute .rownumber > > > > > > > > This read-only attribute should provide the current 0-based > > > > index of the cursor in the result set or -1 if the index cannot > > > > be determined. > > > > > > Didn't we decide that None was a better choice for this? > > > > Correct. I must have forgotten to update this part. > > mm.. wasn't None for .lastrowid and -1 for .rownumber? You could be right. Even so, None is a better return value for .rownumber. I don't know for a fact that there are no databases which have negative row numbers, but I do know none of them have a row number of None... -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From mal@lemburg.com Tue Nov 27 09:09:14 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 27 Nov 2001 10:09:14 +0100 Subject: [DB-SIG] Extensions to DB API 2.0 References: <3BFE332B.F80A9248@lemburg.com> <1006573891.2012.5.camel@chef.comstar.net> <3BFFB491.633B8D9D@lemburg.com> <1006642498.602.2.camel@nenya> <1006816522.12410.27.camel@chef.comstar.net> Message-ID: <3C03583A.61B3E4CA@lemburg.com> Andy Dustman wrote: > > > > > > Cursor Attribute .rownumber > > > > > > > > > > This read-only attribute should provide the current 0-based > > > > > index of the cursor in the result set or -1 if the index cannot > > > > > be determined. > > > > > > > > Didn't we decide that None was a better choice for this? > > > > > > Correct. I must have forgotten to update this part. > > > > mm.. wasn't None for .lastrowid and -1 for .rownumber? > > You could be right. Even so, None is a better return value for > .rownumber. I don't know for a fact that there are no databases which > have negative row numbers, but I do know none of them have a row number > of None... How about using None for both attributes ?! In retrospective, I think that using -1 for .rowcount was the wrong decision -- perhaps we can change that in DB-API spec 3.0 too. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From fog@debian.org Tue Nov 27 09:38:19 2001 From: fog@debian.org (Federico Di Gregorio) Date: 27 Nov 2001 10:38:19 +0100 Subject: [DB-SIG] Extensions to DB API 2.0 In-Reply-To: <3C03583A.61B3E4CA@lemburg.com> References: <3BFE332B.F80A9248@lemburg.com> <1006573891.2012.5.camel@chef.comstar.net> <3BFFB491.633B8D9D@lemburg.com> <1006642498.602.2.camel@nenya> <1006816522.12410.27.camel@chef.comstar.net> <3C03583A.61B3E4CA@lemburg.com> Message-ID: <1006853899.560.2.camel@nenya> --=-eB8B4gnVwZA4H1GPfnfg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2001-11-27 at 10:09, M.-A. Lemburg wrote: [snip] > How about using None for both attributes ?! In retrospective, > I think that using -1 for .rowcount was the wrong decision -- perhaps > we can change that in DB-API spec 3.0 too. agreed. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org The number of the beast: vi vi vi. -- Delexa Jones --=-eB8B4gnVwZA4H1GPfnfg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjwDXwsACgkQvcCgrgZGjev6IgCfTF0THWKHbAFGXQ8MHH3ZUq48 I8AAoJFdifNNRt8RNOX3ch3MyjtTlJnF =P1w5 -----END PGP SIGNATURE----- --=-eB8B4gnVwZA4H1GPfnfg--