> [Guido] > > ... > > I've discovered another reason not to *require* the new module: new is > > not allowed in restricted mode. Without this patch, this means that > > any import from __future__ would fail, and in turn e.g. "import types" > > would fail. > > > > I'm beginning to wonder if sticking the CO_ constants in __future__ > > was such a good idea... > > Sure it was. The problem has nothing to do with __future__, it has to do > with a failure of introspection, i.e. that the CO_xxx flags weren't exposed > anywhere. That also causes by-hand duplication of the magic little integers > in pyassem.py. We wouldn't have any problems if I had picked some module > other than "new" to host them (well, any other module that happens always to > be available, unlike "new"); but "new" is the module they fit best. I could > move 'em to, e.g., sys. Sys would make more sense, for sure. --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