Fixed issue where part of the utility language helper internals was passing
the wrong kind of argument to the Python ``__import__`` builtin as the list
of modules to be imported. The issue produced no symptoms within the core
library but could cause issues with external applications that redefine the
``__import__`` builtin or otherwise instrument it. Pull request courtesy Joe
Urciuoli.
Per the submitter: "The fourth argument provided to `__import__` (which
`import_` feeds in to) is supposed to be a a list of strings, but this code is
passing a single string. This was causing the sqlalchemy `import_` function to
break the string (for example 'interfaces') into an array of single characters
['i', 'n', ...], which causes the actual `__import__` to not find the module
`sqlalchemy.orm.i` (since it's trying to import `sqlalchemy.orm.i` and
`sqlalchemy.orm.n` .. etc)"
No issue could be reproduced locally as it seems you can put anything non-
empty/None into that last argument, even a list like ``['X']``, and all the
sub-modules seem to appear. Omit it, and then the sub-modules aren't present.
Perhaps it just runs the module or not if this attribute is present.