check for iter in base.py __distill_params is not py3k compatible

original issue:

in dialects/firebird/base.py c = connection.execute(keyqry, KEY", tablename) but the string "PRIMARY KEY" and tablename get converted to arrays before keyqry is passed to the driver.

sqlalchemy.exc.ProgrammingError: (ProgrammingError) Statement parameter sequence contains 11 parameters, but only 10 are allowed '\n SELECT se.rdb$field_name AS fname\n FROM rdb$relation_constraints rc\n JOIN rdb$index_segments se ON rc.rdb$index_name=se.rdb$index_name\n WHERE rc.rdb$constraint_type=? AND rc.rdb$relation_name=?\n ' ['R', 'I', 'M', 'A', 'R', 'Y', ' ', 'K', 'E', 'Y'), ('A', 'C', 'C', 'O', 'U', 'N', 'T')](('P',)

test script returns different results in py2k vs py3k, due to the hardcoded check for iter:

def distill_params(multiparams, params):
    """Given arguments from the calling form *multiparams, **params,
    return a list of bind parameter structures, usually a list of
    dictionaries.

    In the case of 'raw' execution which accepts positional parameters,
    it may be a list of tuples or lists.

    """

    if not multiparams:
        if params:
            return [params](params)
        else:
            return [   elif len(multiparams) == 1:
        zero = multiparams[0](]
)
        if isinstance(zero, (list, tuple)):
            print ("1")
            if not zero or hasattr(zero[0](0), '__iter__'):
                return zero
            else:
                return [zero](zero)
        elif hasattr(zero, 'keys'):
            print ("2")
            return [zero](zero)
        else:
            print ("3")
            return [[zero]([zero)]
    else:
        if hasattr(multiparams[0](0), '__iter__'):
            print ("4")

            return multiparams
        else:
            print ("5")
            return [multiparams](multiparams)


print (distill_params(("word1", "word2"), {}))
print (distill_params(["word2"]("word1",), {}))

py2k uses codepath 5, py3k uses codepath 4.

What is deeply mysterious here, is how all the tests in test_execute and otherwise all pass on Py3K using the sqlite dialect, which is positional. This will need to be investigated.

Comments (5)