[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.
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