Pyroot with from ROOT import *

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())
print len(vars())
print “TFile” in dict(vars())

Hi @Andrew1,

I just tried from lxplus, with ROOT 6.12 (in LCG 93):

[etejedor@lxplus044 ~]$ source /cvmfs/ 
[etejedor@lxplus044 ~]$ python
Python 2.7.13 (default, Dec  5 2017, 19:29:24) 
[GCC 6.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ROOT import *
>>> print len(vars())
>>> print 'TFile' in dict(vars())
>>> TFile()
<ROOT.TFile object at 0x3284210>
>>> print len(vars())
>>> print 'TFile' in dict(vars())

The length of the list seems to be updated correctly.

Admittedly, from ROOT import * is not supported in Python3, but it should be ok in Python2:

What is exactly the error that you see?



Hi @etejedor,

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.

xoffsetstart = 1

from ROOT import *

from ROOT import TFile

a1 = 1
a2 = 1
a3 = 1
a4 = 1
a5 = 1
a6 = 1
a7 = 1
a8 = 1
a9 = 1

print xoffsetstart



Hi Andrew1,

I was able to reproduce and this looks indeed like a bug. I have opened a ticket to follow the issue:

In the meantime, I suggest you just stick to importing individual classes.


Hah, some really old history there that is long since gone in cppyy master.

One possible fix is to add:


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, which makes it a different object leading to a different set of lookup functions. Needless to say that consistency helps. :slight_smile:

Oh, and from cppyy.interactive import * works for p3, too.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.