Re: RFC: Extend psycopg2.connect to accept all valid parameters?
От | Federico Di Gregorio |
---|---|
Тема | Re: RFC: Extend psycopg2.connect to accept all valid parameters? |
Дата | |
Msg-id | 4EC4C672.3040107@dndg.it обсуждение исходный текст |
Ответ на | Re: RFC: Extend psycopg2.connect to accept all valid parameters? (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: RFC: Extend psycopg2.connect to accept all valid parameters?
|
Список | psycopg |
On 17/11/11 03:02, Daniele Varrazzo wrote: > On Wed, Nov 16, 2011 at 10:23 PM, Daniele Varrazzo > <daniele.varrazzo@gmail.com> wrote: >> > On Wed, Nov 16, 2011 at 9:38 PM, Fabian Knittel >> > <fabian.knittel@avona.com> wrote: >>> >> Instead of implementing the kwargs-pass-through approach in C, I could >>> >> also imagine a solution where psycopg2._psycopg.connect (psyco_connect) >>> >> is changed to only support a single string-DSN-parameter. >>> >> psycopg2.connect would be a pure-Python method that wraps around >>> >> psycopg2._psycopg.connect and provides the kwargs to dsn conversion >>> >> sugar. (This would move all the icky string manipulation stuff from C >>> >> to Python.) >> > >> > Yes, I agree: this is a less scary implementation if you wanted to >> > provide a patch. I'd either leave psycopg2._psycopg.connect as it is, >> > with the currently supported keyword arguments, or rename it to >> > psycopg2._psycopg._connect, supporting only the connection string. >> > Either way, the function would be imported in the module as _connect, >> > to be invoked by a connect() function written in python and >> > responsible to build the connection string. > I've implemented what discussed here and pushed in a separate branch: > https://github.com/dvarrazzo/psycopg/commit/d2b67364fd2b0b192342281d24a7e3d0a4909980 > > It's open for discussion. It is not as tested as the rest of the > library, as there aren't many tests covering connect() in all the > possible ways (as there should be as many databases on the other side > to reply). So it needs some manual testing, or a strategy for > automatic ones, definitely more than the 10 minutes I've tried before > pushing. > > I'd like to hear from somebody else (mostly Fog, but anybody else) > before having it merged and released: tests and feedbacks are welcome. Looks good but I have a question: does automatic conversion always generates a valid connection string? Do we need quoting for some of the parameters? The main idea behind .connect() was to use dsn for the generic case and provider keyword arguments as a utility for the most common cases while the patch actually says "it's ok to use kwargs for everything" and if we do that then it should work out of the box. But I almost always use username+password only so I don't know if some parameters need special treatment. federico -- Federico Di Gregorio fog@initd.org La macchina virtuale elabora quindi dati adempiendo le sue funzioni specifiche senza esistere nella realtà degli oggetti. -- uno studente
В списке psycopg по дате отправления: