From tlocke at tlocke.org.uk Fri Sep 13 19:54:35 2013 From: tlocke at tlocke.org.uk (Tony Locke) Date: Fri, 13 Sep 2013 18:54:35 +0100 Subject: [DB-SIG] DBAPI 3.0: Unified parameter style Message-ID: Hi, I'm a contributor to the PG8000 Postgres driver: https://github.com/mfenniak/pg8000/tree/py3 Having read the interesting DBAPI 3.0 wiki page: https://wiki.python.org/moin/DbApi3 I thought I'd give a suggestion for unified parameters. Apologies if this has been suggested before, I did have a look at the archives :-) In DBAPI 2.0, the parameters to execute() can be a sequence or a mapping. In DBAPI 3.0, the paramstyle attribute should be removed, and the style determined by whether the parameters are a sequence or mapping. For a sequence the 'numeric' style is expected, and for a mapping the 'named' style. For example: execute("select * from emp where name = :1", ['horatio']) execute("select * from emp where name = :name", {'name': 'horatio'}) The reason I like this solution is that if someone asked me how parameters work in DBAPI, this one would be the easiest to explain! Any thoughts? Cheers, Tony. From mal at python.org Mon Sep 16 09:51:21 2013 From: mal at python.org (M.-A. Lemburg) Date: Mon, 16 Sep 2013 09:51:21 +0200 Subject: [DB-SIG] DBAPI 3.0: Unified parameter style In-Reply-To: References: Message-ID: <5236B879.9090307@python.org> The wiki page is somewhat out of date and doesn't really reflect what we've been discussing here on the list recently. We're currently aiming for making the .paramstyle a user adjustable setting and requiring support for two paramstyles 'qmark' and 'named', while keeping the other paramstyles around to maintain backwards compatibility. An application can then decide which paramstyle to use, which makes porting applications easier. Determining the paramstyle by looking at the parameter type was dropped due to the unreliable nature of using this approach: difficulties in detecting mapping vs. sequence, hiding errors and unclear selection of paramstyle (e.g. numeric vs. qmark vs. format vs. pyformat, or even numeric vs. named). Also note that we've been moving DB-API v2 forward by adding standard extensions to it. The above paramstyle support is likely going to become such an extension. DB-API v3 will then most likely just make some of those extensions mandatory and perhaps add some more details with respect to handling Unicode. Perhaps I should update the page with a summary of what we've been discussing here. On 13.09.2013 19:54, Tony Locke wrote: > Hi, I'm a contributor to the PG8000 Postgres driver: > > https://github.com/mfenniak/pg8000/tree/py3 > > Having read the interesting DBAPI 3.0 wiki page: > > https://wiki.python.org/moin/DbApi3 > > I thought I'd give a suggestion for unified parameters. Apologies if > this has been suggested before, I did have a look at the archives :-) > > In DBAPI 2.0, the parameters to execute() can be a sequence or a > mapping. In DBAPI 3.0, the paramstyle attribute should be removed, and > the style determined by whether the parameters are a sequence or > mapping. For a sequence the 'numeric' style is expected, and for a > mapping the 'named' style. For example: > > execute("select * from emp where name = :1", ['horatio']) > > execute("select * from emp where name = :name", {'name': 'horatio'}) > > The reason I like this solution is that if someone asked me how > parameters work in DBAPI, this one would be the easiest to explain! > > Any thoughts? > > Cheers, > > Tony. > _______________________________________________ > DB-SIG maillist - DB-SIG at python.org > https://mail.python.org/mailman/listinfo/db-sig > -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ From cito at online.de Tue Sep 17 13:52:06 2013 From: cito at online.de (Christoph Zwerschke) Date: Tue, 17 Sep 2013 13:52:06 +0200 Subject: [DB-SIG] DBAPI 3.0: Unified parameter style In-Reply-To: <5236B879.9090307@python.org> References: <5236B879.9090307@python.org> Message-ID: <52384266.40303@online.de> Am 16.09.2013 09:51, schrieb M.-A. Lemburg: > Perhaps I should update the page with a summary of what we've been > discussing here. If you can find some time for it, that would be really helpful. -- Christoph From vernondcole at gmail.com Tue Sep 17 14:30:56 2013 From: vernondcole at gmail.com (Vernon D. Cole) Date: Tue, 17 Sep 2013 13:30:56 +0100 Subject: [DB-SIG] DBAPI 3.0: Unified parameter style In-Reply-To: References: Message-ID: Tony: You are not the first one to notice that .paramstyle is rather an obtuse and ungainly creature. I also submitted a suggestion that introspection of the second argument to exectute() could potentially make it nearly obsolete (when there are only two alternative choices). As you have seen, that approach has been rejected by the group as "unreliable" due to "difficulties in detecting..." -- even though I have published code which shows how easy it actually is (in Python). I have also pointed out that the Python3 print() function uses this same technique. I suppose it is more challenging to do it in C code, however, and really not all _that_ useful, compared to being explicit. On Fri, Sep 13, 2013 at 6:54 PM, Tony Locke wrote: > Hi, I'm a contributor to the PG8000 Postgres driver: > > https://github.com/mfenniak/pg8000/tree/py3 > > Having read the interesting DBAPI 3.0 wiki page: > > https://wiki.python.org/moin/DbApi3 > > I thought I'd give a suggestion for unified parameters. Apologies if > this has been suggested before, I did have a look at the archives :-) > > In DBAPI 2.0, the parameters to execute() can be a sequence or a > mapping. In DBAPI 3.0, the paramstyle attribute should be removed, and > the style determined by whether the parameters are a sequence or > mapping. For a sequence the 'numeric' style is expected, and for a > mapping the 'named' style. For example: > > execute("select * from emp where name = :1", ['horatio']) > > execute("select * from emp where name = :name", {'name': 'horatio'}) > > The reason I like this solution is that if someone asked me how > parameters work in DBAPI, this one would be the easiest to explain! > > Any thoughts? > > Cheers, > > Tony. > _______________________________________________ > DB-SIG maillist - DB-SIG at python.org > https://mail.python.org/mailman/listinfo/db-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vernondcole at gmail.com Tue Sep 17 14:41:56 2013 From: vernondcole at gmail.com (Vernon D. Cole) Date: Tue, 17 Sep 2013 13:41:56 +0100 Subject: [DB-SIG] DBAPI 3.0: Unified parameter style In-Reply-To: References: Message-ID: Tony: I should also mention that the reason that "qmark" ("?") delimiters were selected as the choice for specified-by-order parameter markers, rather than "numeric" (":n") in simply popularity. Postgres is pretty much alone in using numeric, where several other popular databases all use qmark. The most important reason for leaving the .paramstyle attribute in place is so that Postgres applications need not be re-written -- we assume that anyone who writes a Postgres adapter will allow "numeric" parameters as an extension to the standard. > On Fri, Sep 13, 2013 at 6:54 PM, Tony Locke wrote: > >> Hi, I'm a contributor to the PG8000 Postgres driver: >> >> https://github.com/mfenniak/pg8000/tree/py3 >> >> Having read the interesting DBAPI 3.0 wiki page: >> >> https://wiki.python.org/moin/DbApi3 >> >> I thought I'd give a suggestion for unified parameters. Apologies if >> this has been suggested before, I did have a look at the archives :-) >> >> In DBAPI 2.0, the parameters to execute() can be a sequence or a >> mapping. In DBAPI 3.0, the paramstyle attribute should be removed, and >> the style determined by whether the parameters are a sequence or >> mapping. For a sequence the 'numeric' style is expected, and for a >> mapping the 'named' style. For example: >> >> execute("select * from emp where name = :1", ['horatio']) >> >> execute("select * from emp where name = :name", {'name': 'horatio'}) >> >> The reason I like this solution is that if someone asked me how >> parameters work in DBAPI, this one would be the easiest to explain! >> >> Any thoughts? >> >> Cheers, >> >> Tony. >> _______________________________________________ >> DB-SIG maillist - DB-SIG at python.org >> https://mail.python.org/mailman/listinfo/db-sig >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.weissberger at craneae.com Wed Sep 18 19:23:03 2013 From: daniel.weissberger at craneae.com (Weissberger, Daniel) Date: Wed, 18 Sep 2013 10:23:03 -0700 Subject: [DB-SIG] SQL Alchemy Database Architecture Question Message-ID: <93E7458CEFAAF34492BADCA974BBB0C10559AAFB@Braves.aerospace.craneae.com> To whom it may concern: I am a system engineer for Crane Aerospace and am considering using SQLAlchemy for ORM. I have a couple of concerns up front I wanted to share with you. The machine running Python will be a QNX RTOS Machine Currently I have 32 bit MS Access installed on a 64 bit machine giving me a setup error with PYODBC ( I had to use PYPYODBC; This was just a temporary setup to test the architecture on my PC). Is this (PYPYODBC) supported/recommended? Seems that there is no SQLAlchemy support for MS Access, is this correct? Given my system (Ideally I would like to host the database on the QNX machine), could you suggest for me the following: 1) A recommended database platform (if there is a method for MS Access this is preferred) 2) Given this database platform, a recommended database API 3) Any other tips and help you can offer in getting this set up would be GREATLY appreciated. Feel free to contact me, via email or phone below Thank You, Daniel Weissberger (818) 825-5853 - Cell (818) 526-3533 - Work ###################################################################### Attention: The information contained in this email message may be privileged and is confidential information intended only for the use of the recipient, or any employee or agent responsible to deliver it to the intended recipient. Any unauthorized use, distribution or copying of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately and destroy the original message and all attachments from your electronic files. ###################################################################### -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlocke at tlocke.org.uk Sat Sep 21 15:55:07 2013 From: tlocke at tlocke.org.uk (Tony Locke) Date: Sat, 21 Sep 2013 14:55:07 +0100 Subject: [DB-SIG] DBAPI 3.0: Unified parameter style In-Reply-To: References: Message-ID: Just for fun I've put up a version of pg8000 that works without a paramstyle parameter: https://github.com/tlocke/pg8000/tree/three In this version, you can do: execute("select * from emp where name = :1", ['horatio']) or: execute("select * from emp where name = :name", {'name': 'horatio'}) The way it works is that the execute() signature remains as: def execute(query, args): and then 'query' is parsed for labels, eg '1' or 'name'. The labels are converted into ints if they can be. Then it evaluates: args[label] To return the correct value. So if 'label' is an int and 'args' is a sequence, the value at that index is returned, and if 'label' is a string and 'args' is a mapping, then the value for that key is returned. The reason I like the :label notation is that it's more convenient for users because it's easy to remember. Having both ? and :key is inconsistent (to my tastes). It'll also lead to inconsistencies in parsing and escaping behaviour. Some people have raised objections to detecting mapping or sequence types of the args. The above approach uses duck typing where we just do args[label] and use what comes back, not caring what args actually is. I'd argue that this is a perfectly acceptable, pythonic way of going about things. Btw, I'm enjoying the list, it's a good group! Cheers, Tony. On 17 September 2013 13:41, Vernon D. Cole wrote: > Tony: > I should also mention that the reason that "qmark" ("?") delimiters were > selected as the choice for specified-by-order parameter markers, rather than > "numeric" (":n") in simply popularity. Postgres is pretty much alone in > using numeric, where several other popular databases all use qmark. > The most important reason for leaving the .paramstyle attribute in place > is so that Postgres applications need not be re-written -- we assume that > anyone who writes a Postgres adapter will allow "numeric" parameters as an > extension to the standard. > > >> >> On Fri, Sep 13, 2013 at 6:54 PM, Tony Locke wrote: >>> >>> Hi, I'm a contributor to the PG8000 Postgres driver: >>> >>> https://github.com/mfenniak/pg8000/tree/py3 >>> >>> Having read the interesting DBAPI 3.0 wiki page: >>> >>> https://wiki.python.org/moin/DbApi3 >>> >>> I thought I'd give a suggestion for unified parameters. Apologies if >>> this has been suggested before, I did have a look at the archives :-) >>> >>> In DBAPI 2.0, the parameters to execute() can be a sequence or a >>> mapping. In DBAPI 3.0, the paramstyle attribute should be removed, and >>> the style determined by whether the parameters are a sequence or >>> mapping. For a sequence the 'numeric' style is expected, and for a >>> mapping the 'named' style. For example: >>> >>> execute("select * from emp where name = :1", ['horatio']) >>> >>> execute("select * from emp where name = :name", {'name': 'horatio'}) >>> >>> The reason I like this solution is that if someone asked me how >>> parameters work in DBAPI, this one would be the easiest to explain! >>> >>> Any thoughts? >>> >>> Cheers, >>> >>> Tony. >>> _______________________________________________ >>> DB-SIG maillist - DB-SIG at python.org >>> https://mail.python.org/mailman/listinfo/db-sig >> >> >