From: Richard W. <ric...@gm...> - 2015-04-13 19:41:02
|
I posted something about this problem to the list a few days ago, but I think I have a better idea of what exactly is causing the problem. The basic behavior was when running “build_exe” on my project I would get a traceback with a “maximum recursion depth exceeded”. I tracked this down to something related to the six package and “from” style imports. Originally I believed that all “from” style imports were causing the error, but through debugging the build process I have found that only when “from six.moves.subpackage” and “from six.moves.subpackage.subsubpackage” are causing the error. In particular, in “google_api_python_client” 1.4.0, in googleapiclient/discovery.py there is a line from six.moves.urllib.parse import urlencode, urlparse, urljoin, urlunparse, parse_sql If I step through the build process in a debugger, it looks like it starts to find modules and eventually causes a loop where _find_and_load is originally called with six.moves.urllib.parse and then settles into a loop with six.moves.urllib as the name. The loop seems to “reoccur" in __getattr__ in hooks.py:288 (which itself is called from mf3.py:300). It calls self.__finder.safe_import_hook which restarts the safe_import_hook->import_hook->_gcd_import->_find_and_load->__getattr__ loop. Some information about my setup: Python 3.4.3 on Windows 8.1, py2exe 0.9.2.2. Finally, it is only my theory that from six.moves.<subpackages> is the root cause. It may still be something specific to six.moves.urllib.parse - that is just the only example I have of the problem occurring. Any help would be appreciated. Thanks. |