[PyROOT] ROOT package import method changes gDirectory.pwd() result

[kdrazyk]

Check duplicate issues.

• Checked for duplicates

Description

import ROOT and from ROOT import TFile, gDirectory yield different results on our systems running ROOT 6.36.04, 6.36.10 and 6.38.0.
On systems with ROOT 6.34.04 and 6.34.10 both methods produce the same results.
I expected the package to work the same way no matter the import syntax.

Python 3.12.12 (main, Feb 27 2026, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-11)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from ROOT import TFile, gDirectory, gROOT
>>> TFile("Hybrid.root")
<cppyy.gbl.TFile object at 0x556042225510>
>>> gDirectory.pwd()
PyROOT:/
>>> gROOT.GetVersion()
'6.36.10'

Python 3.12.12 (main, Feb 27 2026, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-11)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ROOT
>>> ROOT.TFile("Hybrid.root")
<cppyy.gbl.TFile object at 0x563f2d4c3870>
>>> ROOT.gDirectory.pwd()
Hybrid.root:/
>>> ROOT.gROOT.GetVersion()
'6.36.10'

I expected both cases to produce: Hybrid.root:/

Reproducer

To be run from Python REPL

from ROOT import TFile, gDirectory
TFile("Hybrid.root")
gDirectory.pwd()

import ROOT
ROOT.TFile("Hybrid.root")
ROOT.gDirectory.pwd()

I can't attach the ROOT file, but it's small and simple.

>>> import ROOT
>>> f = ROOT.TFile("Hybrid.root")
>>> f.ls()
TFile**		Hybrid.root	
 TFile*		Hybrid.root	
  KEY: TTree	summaryTree;1	Most relevant results
  KEY: TTree	tI2CMaster0;1	I2C Master 0 Test Tree
  KEY: TTree	tI2CMaster2;1	I2C Master 2 Test Tree

ROOT version

   ------------------------------------------------------------------
  | Welcome to ROOT 6.36.10                        https://root.cern |
  | (c) 1995-2025, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Mar 13 2026, 14:55:50                 |
  | From tags/v6-36-10@v6-36-10                                      |
  | With c++ (GCC) 11.5.0 20240719 (Red Hat 11.5.0-11)               |
  | Try '.help'/'.?', '.demo', '.license', '.credits', '.quit'/'.q'  |
   ------------------------------------------------------------------

Installation method

Pre-built binary: https://root.cern/download/root_v6.36.10.Linux-almalinux9.7-x86_64-gcc11.5.tar.gz

Operating system

CERN Alma Linux 9

Additional context

No response

[guitargeek]

The gDirectory macro is one of the most complicated codes in ROOT, and even after 2 hours thinking about about it, I have no clue what changed the behavior. It could be in many layers in the software, as these macros are also treated specially by Cling to expose them to the reflection system.

So unless @vepadulano or @aaronj0 have a quick intuition on what's going on, I will just do an automatic git bisect to find the commit that changed the behavior, but this might take some time.

[kdrazyk]

Thank you. Luckily the workaround is simple and we fixed the issue on our side, but a bug like this makes me a little paranoid about working with our ROOT codebase. Finding this bug took a lot of time, because we didn't expect import syntax could matter.

[guitargeek]

Well, it was nothing to do with the import actually. It's just that gDirectory is crazy. You might think it's just a TDirectory * pointer, but look at the implementation:
https://github.com/root-project/root/blob/master/core/base/inc/TDirectory.h#L385

It's actually defined as instantiating a new ::ROOT::Internal::TDirectoryAtomicAdapter{}, which implicitly converts to a TDirectory pointer! Depending on when that implicit conversion happens, you will get a pointer to what the TDirectory was at the time of the implicit conversion. It seems that with newer ROOT versions, the implicit conversion happens earlier, giving you the global directory from before you opened the file.

Here is an example to illustrate this:

import ROOT

print("ROOT", ROOT.__version__)

# pointers to the directory at this point...
# ...with the gDirectory macro
gDirectory_1 = ROOT.gDirectory
# ...using directory the C++ that the macro would give you from implicit conversion
gDirectory_2 = ROOT.TDirectory.CurrentDirectory().load()

f = ROOT.TFile("Hybrid.root", "RECREATE")

gDirectory_3 = ROOT.gDirectory

print(gDirectory_1)
print(gDirectory_2)
print(gDirectory_3)

The output with ROOT 6.38:

ROOT 6.38.02
Name: PyROOT Title: The ROOT of EVERYTHING
Name: PyROOT Title: The ROOT of EVERYTHING
Name: Hybrid.root Title:

And with ROOT 6.34:

ROOT 6.34.04
Name: Hybrid.root Title:
Name: PyROOT Title: The ROOT of EVERYTHING
Name: Hybrid.root Title:

You can see the "root" of the problem also when you write some C++:

auto gDirectory_1 = gDirectory;
auto &gDirectory_2 = *gDirectory;

TFile f{"Hybrid.root", "RECREATE"};

auto gDirectory_3 = gDirectory;

gDirectory_1->pwd();
gDirectory_2.pwd();
gDirectory_3->pwd();

Indeed gDirectory_1 and gDirectory_2 are not the same, because gDirectory_1 gets only implicitly converted to the current directory later:

Hybrid.root:/
Rint:/
Hybrid.root:/

Pretty confusing for me when I look at the C++ already, no surprise that the Python bindings get confused too. Something must have changed after 6.34 with the implicit conversion rules in PyROOT, which results in the different behavior for this pathological case.

Actually, the original sin was to make gDirectory such an intuitive object. It should never have existed, and users should have been encouraged to use TDirectory::CurrentDirectory()::load() directly, or some helper function, to unambiguously get a TDirectory * pointer and not some object that lazily evaluates to it on conversion. @hageboeck, this is something we should consider to improve for ROOT 7 I think.

[guitargeek]

I concluded my bisection, and the offending commit is e93464a (with followup 1dc46e8 in the same PR) from the ROOT 6.38 development cycle, which also made it into the 6.36.02 patch release as a backport (556c00d).

The PR was:

• [cppyy] handle polymorphic types when converting from class fields #19154

@Vipul-Cariappa, you think there is anything you can do to fix the regression reported here?

I'm optimistic that we can sort this out quickly: the commit only changed a few lines, so it should not be too hard to get to the bottom of this. Vipul is on vacation though, but I'll also try to make some progress without him.