----
* Added 'modulegraph.modulegraph.InvalidSourceModule'. This graph node is
used for Python source modules that cannot be compiled (for example because
they contain syntax errors).
This is primarily useful for being able to create a graph for packages
that have python 2.x or python 3.x compatibility in separate modules that
contain code that isn't valid in the "other" python version.
* Added 'modulegraph.modulegraph.InvalidCompiledModule'. This graph node
is used for Python bytecode modules that cannot be loaded.
* Added 'modulegraph.modulegraph.NamespacePackage'.
Patch by bitbucket user htgoebel.
* No longer add a MissingModule node to the graph for 'collections.defaultdict'
when using 'from collections import defaultdict' ('collections.defaultdict'
is an attribute of 'collections', not a submodule).
* Fixed typo in ModuleGraph.getReferences()
* Added ModuleGraph.getReferers(tonode). This methods yields the
nodes that are referencing *tonode* (the reverse of getReferences)
* The graph will no longer contain MissingModule nodes when using 'from ... import name' to
import a global variable in a python module.
There will still be MissingModule nodes for global variables in C extentions, and
for 'from missing import name' when 'missing' is itself a MissingModule.
* Issue #18: Don't assume that a PEP 302 loader object has a ``path`` attribute. That
attribute is not documented and is not always present.
modulegraph determines a dependency graph between Python modules primarily by
bytecode analysis for import statements.
modulegraph uses similar methods to modulefinder from the standard library, but
uses a more flexible internal representation, has more extensive knowledge of
special cases, and is extensible.
