> Tim's latest change to __future__.py has toasted the build process. Python > itself builds fine, then is run to build the extensions. > > site imports distutils > distutils imports re > re imports sre > sre imports copy_reg > copy_reg imports types > types imports __future__ > __future__ imports new, uh oh, new doesn't yet exist... > > python then tries to keep going but with distutils non-functional, > it doesn't stand a chance. > > If the new module is now considered mainstream, maybe it could be built > statically? Good catch! (This uncovered some problems in my setup -- I hadn't picked up the latest versions of a few modules. :-( ) I solved it a little differently, by adding hackery to __future__ that avoids the dependency. But maybe you're right and it should be built statically (it's in the main DLL on Windows). --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4