(self, user_module=None, user_ns=None)
| 1242 | default_user_namespaces = True |
| 1243 | |
| 1244 | def init_create_namespaces(self, user_module=None, user_ns=None): |
| 1245 | # Create the namespace where the user will operate. user_ns is |
| 1246 | # normally the only one used, and it is passed to the exec calls as |
| 1247 | # the locals argument. But we do carry a user_global_ns namespace |
| 1248 | # given as the exec 'globals' argument, This is useful in embedding |
| 1249 | # situations where the ipython shell opens in a context where the |
| 1250 | # distinction between locals and globals is meaningful. For |
| 1251 | # non-embedded contexts, it is just the same object as the user_ns dict. |
| 1252 | |
| 1253 | # FIXME. For some strange reason, __builtins__ is showing up at user |
| 1254 | # level as a dict instead of a module. This is a manual fix, but I |
| 1255 | # should really track down where the problem is coming from. Alex |
| 1256 | # Schmolck reported this problem first. |
| 1257 | |
| 1258 | # A useful post by Alex Martelli on this topic: |
| 1259 | # Re: inconsistent value from __builtins__ |
| 1260 | # Von: Alex Martelli <aleaxit@yahoo.com> |
| 1261 | # Datum: Freitag 01 Oktober 2004 04:45:34 nachmittags/abends |
| 1262 | # Gruppen: comp.lang.python |
| 1263 | |
| 1264 | # Michael Hohn <hohn@hooknose.lbl.gov> wrote: |
| 1265 | # > >>> print type(builtin_check.get_global_binding('__builtins__')) |
| 1266 | # > <type 'dict'> |
| 1267 | # > >>> print type(__builtins__) |
| 1268 | # > <type 'module'> |
| 1269 | # > Is this difference in return value intentional? |
| 1270 | |
| 1271 | # Well, it's documented that '__builtins__' can be either a dictionary |
| 1272 | # or a module, and it's been that way for a long time. Whether it's |
| 1273 | # intentional (or sensible), I don't know. In any case, the idea is |
| 1274 | # that if you need to access the built-in namespace directly, you |
| 1275 | # should start with "import __builtin__" (note, no 's') which will |
| 1276 | # definitely give you a module. Yeah, it's somewhat confusing:-(. |
| 1277 | |
| 1278 | # These routines return a properly built module and dict as needed by |
| 1279 | # the rest of the code, and can also be used by extension writers to |
| 1280 | # generate properly initialized namespaces. |
| 1281 | if (user_ns is not None) or (user_module is not None): |
| 1282 | self.default_user_namespaces = False |
| 1283 | self.user_module, self.user_ns = self.prepare_user_module(user_module, user_ns) |
| 1284 | |
| 1285 | # A record of hidden variables we have added to the user namespace, so |
| 1286 | # we can list later only variables defined in actual interactive use. |
| 1287 | self.user_ns_hidden = {} |
| 1288 | |
| 1289 | # Now that FakeModule produces a real module, we've run into a nasty |
| 1290 | # problem: after script execution (via %run), the module where the user |
| 1291 | # code ran is deleted. Now that this object is a true module (needed |
| 1292 | # so doctest and other tools work correctly), the Python module |
| 1293 | # teardown mechanism runs over it, and sets to None every variable |
| 1294 | # present in that module. Top-level references to objects from the |
| 1295 | # script survive, because the user_ns is updated with them. However, |
| 1296 | # calling functions defined in the script that use other things from |
| 1297 | # the script will fail, because the function's closure had references |
| 1298 | # to the original objects, which are now all None. So we must protect |
| 1299 | # these modules from deletion by keeping a cache. |
| 1300 | # |
| 1301 | # To avoid keeping stale modules around (we only need the one from the |
no test coverage detected