I have noticed that using “from ROOT import *” causes runtime crashes starting in ROOT 6.03.04. I am using x86_64-slc6 and python 2.7.4. Python’s internal list of variables is corrupted when a TFile is created, as illustrated below. A “TFile” entry is added to python’s internal list of variables, but the length of the internal list is not changed. When “import ROOT” is used instead, this problem does not occur.
from ROOT import *
print len(vars())
print “TFile” in dict(vars())
TFile()
print len(vars())
print “TFile” in dict(vars())
Yes, when I use that environment, it works for me also. Could you please try running the example below, not in the command-line interpreter, but by calling python with a file argument.
Hah, some really old history there that is long since gone in cppyy master.
One possible fix is to add:
mp->ma_fill++;
mp->ma_used++;
before returning ep if gval is not nullptr.
Alternatively, just drop that whole lookup (I suspect that special-casing ROOT globals hasn’t been necessary since the introduction of the memory regulator, but can’t be sure as that commit history is gone b/c of some file renaming). Or treat the use of gval the same as val that just follows it, using the normal dictionary insertion like for any other global.
In the case of cppyy master, it does not mix top-level python thingies (live on module cppyy) with global C++ thingies (live in cppyy.gbl) with import * hooks (live in cppyy.interactive) with the ROOT:: namespace (lives in cppyy.gbl.ROOT). Neither does it special-case the global namespace, which is a C++ namespace like any other, as opposed to ROOT.py, which makes it a different object leading to a different set of lookup functions. Needless to say that consistency helps.
Oh, and from cppyy.interactive import * works for p3, too.