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.
Change-Id: Ia15c74620f24d24f0df4882f9b36a04e2c3725b8
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/473
--- /dev/null
+.. change::
+ :tags: bug, misc
+
+ 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.
# unfortunately importlib doesn't work that great either
tokens = modulename.split(".")
mod = compat.import_(
- ".".join(tokens[0:-1]), globals(), locals(), tokens[-1])
+ ".".join(tokens[0:-1]), globals(), locals(), [tokens[-1]])
mod = getattr(mod, tokens[-1])
setattr(mod, obj.__name__, obj)
return obj