Context manager for TFile

ROOT
1

Dear PyROOT authors,

i think it would be nice to have a context manager for TFile objects, in order to open and close root files in a more pythonic manner:

with ROOT.TFile('MyFile.root') as f:
    h = f.Get('MyHistogram')
    h.SetDirectory(0)

h.Draw()  # use the histogram...

Cheers,
-Heiner

1 Like
2

Hi Heiner,

thanks for your post: nice proposal.
Indeed this is an idea floating around since a while. We’ll discuss this in one of the next meetings.

Cheers,
Danilo

3

Dear all,

was there any progress with that (right now it looks I can’t use that)? Should we make a feature request, or was it already created?

That would be great to have this feature for uniformity with other Python code (and safety, convenience, etc.)

Cheers,
Yaroslav

4

I do not think there was anything new in that area. May be @etejedor can give more details. I think he will be able to tell you if that’s something which can be done (and may be open a github request/issue).

5

Hello,

No, there is no such feature yet in PyROOT. One complication of that feature is the fact that the object retrieved from the file needs to be disconnected from the file, otherwise the internal memory management of ROOT will destroy that object after the context manager block finishes (the SetDirectory(0) in the example).

6

As I understand, the general workflow with ROOT and Python files (and what I usually do) is to open a file, get some information out there (for example, to yield some events/parsed lines), and close that. Python with statement works fine for that. If one needs to use data outside the with block, one should care about that him/herself. I see no difference with Open/Close calls (apart from the syntax and features). Am I missing something?

7

The difference is that, in the context manager case, users need to explicitly disconnect the objects they retrieve from the file. If you don’t have a context manager, it is common that you don’t even close the file in your app (when the app ends, the file object will be destructed and that will close the file anyway), so you don’t need to worry about disconnecting the objects you retrieved.

8

Why don’t you implement the context manager as Open and Close, so all is done automatically as for the usual workflow? I don’t think that not closing the file should be encouraged… If one doesn’t want to close the file, one may just use the Open method.

9

I thought this was implied from the beginning, and this is also the cause of the problems. Retrieved objects won’t survive beyond the context manager block without explicit user intervention.

I don’t think that not closing the file should be encouraged

Closing the file in the destructor of TFile makes sure resources are properly released, both in Python and in C++, and it also allows users to keep their retrieved objects alive (or not care about it).

Bottom line, I think the context manager construct for TFile is a nice idea, I’m just worried about the clash it has with internal ROOT memory management system of TFile-linked objects and the issues this might cause.