[DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

[Daniele Varrazzo]

On Fri, May 17, 2013 at 5:07 PM, Michael Bayer <mike_mp at zzzcomputing.com> wrote:
>
> On May 17, 2013, at 11:36 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>
>> On 17.05.2013 17:10, Christoph Zwerschke wrote:
>>> Am 17.05.2013 17:01, schrieb Vernon D. Cole:
>>>> What other options should be considered?
>>>
>>> Another option would be to get rid of the parameter completely, and silently accept both styles,
>>> whatever is used in the sql command passed to the execute method.
>>
>> This would violate explicit is better than implicit, and it also
>> creates problems with raising proper errors, e.g. passing a
>> dictionary of parameters to a SQL command which uses a mix
>> of qmark and named style parameter markers.
>>
>> We do need to keep this explicit.
>
>
> IMHO it is explicit, whether you say:
>
> cursor.execute(stmt, { < dictionary>} )
>
> vs.
>
> cursor.execute(stmt, [ <list>] )
>
> the type of parameters passed indicates the style of params to search for.   It's explicit via type inference.    if a dictionary is passed, "?" symbols are left alone.  If a list is passed, ":param" symbols are left alone.  If neither is passed, then neither ? nor :param are searched for.

This only resolves the ambiguity between positional or mapping
arguments. It doesn't help a driver to disambiguate between two
different mapping styles, such as named or pyformat.

-- Daniele