[DB-SIG] Some obscurity with paramstyle

M.-A. Lemburg mal at egenix.com
Wed Jul 20 11:05:44 CEST 2011


Chris Clark wrote:
> M.-A. Lemburg wrote:
>> Daniele Varrazzo wrote:
>>  
>>>> On Jul 19, 2011 3:44 AM, "Federico Di Gregorio"
>>>> <federico.digregorio at dndg.it> wrote:
>>>>      
>>>>> At least 2 drivers (psycopg and pysqlite) provide a Python->backend
>>>>> mechanism based on PEP 246, "Object Adaptation". If other implementors
>>>>> are interested I can write a short explanation about how it works and
>>>>> why it was chosen only for the Python->backend path and not for the
>>>>> reverse.
>>>>>         
>>> On Tue, Jul 19, 2011 at 11:05 AM, Vernon Cole <vernondcole at gmail.com>
>>> wrote:
>>>    
>>>> Yes, please. I would like to see that. Adodbapi has an output
>>>> conversion
>>>> mechanism, but I don't like it particularly well.
>>>>       
>>> For a description:
>>>
>>> http://initd.org/psycopg/docs/advanced.html#adapting-new-python-types-to-sql-syntax
>>>
>>> http://initd.org/psycopg/docs/advanced.html#type-casting-of-sql-types-into-python-objects
>>>
>>>     
>>
>> While this is a nice system, it's also very slow. It uses function
>> calls and string parsing/conversion for adapting each value. This
>> works if you only have to insert/fetch a few rows, but won't be
>> feasible for larger volumes.
>>
>> I think we need something more low-level, which tries to
>> avoid (Python) function calls if possible, .....
> 
> I have to confess the only piece of pep-0246 I read was:
> 
>>
>>       Rejection Notice
>>
>>     I'm rejecting this PEP.  Something much better is about to happen;
>>     it's too early to say exactly what, but it's not going to resemble
>>     the proposal in this PEP too closely so it's better to start a new
>>     PEP.  GvR.
>>   
> 
> Does anyone know what the "better" option was? The date on the pep is a
> number of years ago.

Not that I'm aware off.

Python has moved on to ABCs, which address part of the intended
use in a different way (the outside objects have to implement the
protocol and announce this using an ABC).

The adapter pattern is still useful, though. I just think that
we need to provide a way for database modules to implement
such adapter in straight C (as well as in Python) rather than
requiring a round-trip to Python in all cases.

The sketch I drew up would allow for this. Most database modules
use such C adapters in some form anyway, so these would just
need to be refactored a little bit to make them available
to the Python application, which should help with the adoption
of the new techniques.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 20 2011)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


More information about the DB-SIG mailing list