After instaling the latest version, I discovered that our singular use of
namedresult() is broken, following the pygres implementation of LRU cache,
since our field names includes underscores, which are not "isalnum()".

I see the restriction on names is an approximation of what's allowed in
namedtuple() itself:
https://docs.python.org/2/library/collections.html#namedtuple-factory-function-for-tuples-with-named-fields
|Any valid Python identifier may be used for a fieldname except for names
|starting with an underscore. Valid identifiers consist of letters, digits, and
|underscores but do not start with a digit or underscore and cannot be a keyword
|such as class, for, return, global, pass, print, or raise.

We could work around it pretty easily, but I wanted to mention it since it's a
behavior change in a patchlevel release, since underscore is a very common
identifier separator (as it doesn't require column quoting), since and since
the "fallback" column names use underscores, and since the behavior is somewhat
overly-restrictive.  It's not clear to me if there's any reason not to let
namedtuple raise ValueError for any prohibited names, rather than renaming them
to column_n, especially since that behavior of pygresql isn't documented.
(But, that would mean that query("SELECT *").namedtuple() would crash a program
if a column was added which was an invalid name).

Justin

def _row_factory(names):
    """Get a namedtuple factory for row results with the given names."""
    try:
        try:
            return namedtuple('Row', names, rename=True)._make
        except TypeError:  # Python 2.6 and 3.0 do not support rename
            names = [v if v.isalnum() else 'column_%d' % (n,)
                     for n, v in enumerate(names)]
            return namedtuple('Row', names)._make
    except ValueError:  # there is still a problem with the field names
        names = ['column_%d' % (n,) for n in range(len(names))]
        return namedtuple('Row', names)._make
_______________________________________________
PyGreSQL mailing list
[email protected]
https://mail.vex.net/mailman/listinfo.cgi/pygresql

Reply via email to