(self, user_module=None, user_ns=None)
| 1196 | default_user_namespaces = True |
| 1197 | |
| 1198 | def init_create_namespaces(self, user_module=None, user_ns=None): |
| 1199 | # Create the namespace where the user will operate. user_ns is |
| 1200 | # normally the only one used, and it is passed to the exec calls as |
| 1201 | # the locals argument. But we do carry a user_global_ns namespace |
| 1202 | # given as the exec 'globals' argument, This is useful in embedding |
| 1203 | # situations where the ipython shell opens in a context where the |
| 1204 | # distinction between locals and globals is meaningful. For |
| 1205 | # non-embedded contexts, it is just the same object as the user_ns dict. |
| 1206 | |
| 1207 | # FIXME. For some strange reason, __builtins__ is showing up at user |
| 1208 | # level as a dict instead of a module. This is a manual fix, but I |
| 1209 | # should really track down where the problem is coming from. Alex |
| 1210 | # Schmolck reported this problem first. |
| 1211 | |
| 1212 | # A useful post by Alex Martelli on this topic: |
| 1213 | # Re: inconsistent value from __builtins__ |
| 1214 | # Von: Alex Martelli <aleaxit@yahoo.com> |
| 1215 | # Datum: Freitag 01 Oktober 2004 04:45:34 nachmittags/abends |
| 1216 | # Gruppen: comp.lang.python |
| 1217 | |
| 1218 | # Michael Hohn <hohn@hooknose.lbl.gov> wrote: |
| 1219 | # > >>> print type(builtin_check.get_global_binding('__builtins__')) |
| 1220 | # > <type 'dict'> |
| 1221 | # > >>> print type(__builtins__) |
| 1222 | # > <type 'module'> |
| 1223 | # > Is this difference in return value intentional? |
| 1224 | |
| 1225 | # Well, it's documented that '__builtins__' can be either a dictionary |
| 1226 | # or a module, and it's been that way for a long time. Whether it's |
| 1227 | # intentional (or sensible), I don't know. In any case, the idea is |
| 1228 | # that if you need to access the built-in namespace directly, you |
| 1229 | # should start with "import __builtin__" (note, no 's') which will |
| 1230 | # definitely give you a module. Yeah, it's somewhat confusing:-(. |
| 1231 | |
| 1232 | # These routines return a properly built module and dict as needed by |
| 1233 | # the rest of the code, and can also be used by extension writers to |
| 1234 | # generate properly initialized namespaces. |
| 1235 | if (user_ns is not None) or (user_module is not None): |
| 1236 | self.default_user_namespaces = False |
| 1237 | self.user_module, self.user_ns = self.prepare_user_module(user_module, user_ns) |
| 1238 | |
| 1239 | # A record of hidden variables we have added to the user namespace, so |
| 1240 | # we can list later only variables defined in actual interactive use. |
| 1241 | self.user_ns_hidden = {} |
| 1242 | |
| 1243 | # Now that FakeModule produces a real module, we've run into a nasty |
| 1244 | # problem: after script execution (via %run), the module where the user |
| 1245 | # code ran is deleted. Now that this object is a true module (needed |
| 1246 | # so doctest and other tools work correctly), the Python module |
| 1247 | # teardown mechanism runs over it, and sets to None every variable |
| 1248 | # present in that module. Top-level references to objects from the |
| 1249 | # script survive, because the user_ns is updated with them. However, |
| 1250 | # calling functions defined in the script that use other things from |
| 1251 | # the script will fail, because the function's closure had references |
| 1252 | # to the original objects, which are now all None. So we must protect |
| 1253 | # these modules from deletion by keeping a cache. |
| 1254 | # |
| 1255 | # To avoid keeping stale modules around (we only need the one from the |
no test coverage detected