MCPcopy Index your code
hub / github.com/ipython/ipython / init_create_namespaces

Method init_create_namespaces

IPython/core/interactiveshell.py:1244–1320  ·  view source on GitHub ↗
(self, user_module=None, user_ns=None)

Source from the content-addressed store, hash-verified

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

Callers 1

__init__Method · 0.95

Calls 1

prepare_user_moduleMethod · 0.95

Tested by

no test coverage detected