In Python, RNTupleReader no longer iterable

[rybkine]

Check duplicate issues.

• Checked for duplicates

Description

Firstly, it ought to be iterable since it is iterable in C++. Secondly, such iterablity is Pythonic and is a convenient feature.

Reproducer

$ python -m unittest -v -k Iter >& log.txt

log.txt

validateRootFile_iter.py

test_validateRootFile.py

validateRootFile_range.py

ROOT version

$ root -q

| Welcome to ROOT 6.41.01 https://root.cern |
| (c) 1995-2025, The ROOT Team; conception: R. Brun, F. Rademakers |
| Built for linuxx8664gcc on May 24 2026, 22:55:42 |
| From heads/master@9a7f3e77 |
| With g++ (GCC) 15.2.0 std202302 |
| Try '.help'/'.?', '.demo', '.license', '.credits', '.quit'/'.q' |

Installation method

lcg nightly builds at CERN

Operating system

Red Hat Enterprise Linux release 9.7 (Plow)

Additional context

The bug was introduced by PR #21131.

[dpiparo]

Is this a regression in master or a feature request?

[rybkine]

This is a regression resulted from PR #21131. PR #22432 is an alternative implementation of the context management protocol for RNTupleReader/Writer proposed, which closely follows the implementation in the Python file object and TFile.

[vepadulano]

As I have already explained in the linked PR, this is not a regression. The author of #21131 made a deliberate implementation choice, giving new features and well-defined behaviour to the Python version of the RNTupleReader/Writer classes. The changes in that PR are in no way going against any Python standard.

implementation in the Python file object

This is not a thing. The term file object https://docs.python.org/3/glossary.html#term-file-object refers to a variety of different CPython classes, there is no single implementation. Also, there is nothing written anywhere on whether the RNTupleReader and RNTupleWriter should have any relation with a CPython file object. That could be, but it should be decided and documented by the ROOT project first.

#22432 as it stands now represents an "alternative" in the sense that it completely discards the current implementation arbitrarily and rewrites it. Whether this is the right choice or not, it is in no way a bug fix.

[rybkine]

As I have already explained in the linked PR, this is not a regression.

When a modification breaks an existing functionality, it is called a regression. Is it not?

The author of #21131 made a deliberate implementation choice, giving new features and well-defined behaviour to the Python version of the RNTupleReader/Writer classes. The changes in that PR are in no way going against any Python standard.

The only new feature added was the context manager functionality. However, there was no reason to break any of the existing functionality. Such a breakage goes against any s/w development standard.

The term file object https://docs.python.org/3/glossary.html#term-file-object refers to a variety of different CPython classes, there is no single implementation.

These classes belong to the same inheritance tree. What is important here is that all of them share a single implementation of the context management protocol.

Also, there is nothing written anywhere on whether the RNTupleReader and RNTupleWriter should have any relation with a CPython file object.

RNTupleReader and RNTupleWriter can follow a good example of Python file object how to cleanly implement the context management protocol. That is straightforward, as PR #22432 demonstrates, preserving all the functionality of RNTupleReader and RNTupleWriter.

[vepadulano]

When a modification breaks an existing functionality, it is called a regression. Is it not?
The only new feature added was the context manager functionality. However, there was no reason to break any of the existing functionality. Such a breakage goes against any s/w development standard.

There was no "existing functionality" in this case, anything that may have worked before was not documented thus if any pre-existing implicit functionality is desirable this is ultimately a decision of the ROOT project. Not saying that it's not desirable, just stating that a decision is still to be taken. Once such decision will be taken, the appropriate action will be taken and this issue and related PR will be updated accordingly.

[rybkine]

There was no "existing functionality" in this case, anything that may have worked before was not documented thus if any pre-existing implicit functionality is desirable this is ultimately a decision of the ROOT project.

I would have thought years ago the ROOT project took the decision to provide Python bindings to the framework written in C++. Needless to say they have been and are very successful. This means that the functionality available in C++ is expected to be - and is - present in Python - without any further human decision. There are very rare exceptions but they have only to do with the incompatibilities between C++ and Python. This particular case clearly has nothing to do with such exceptions, and thus does not need any further decisions.

[vepadulano]

This means that the functionality available in C++ is expected to be - and is - present in Python - without any further human decision. There are very rare exceptions but they have only to do with the incompatibilities between C++ and Python.

I am confused about this sentence because the RNTupleReader/Writer classes are definitely falling in the category of functionalities that do not translate 1:1 and need a lot of human intervention (and decision making). This is made evident simply by the fact that there needs to be an explicit Pythonization (i.e., code integrated in ROOT in bindings/...) to expose the C++ functionality to the Python side. And in general I think there is a lot of misconception here, it's not that rare to have incompatibilities between any two programming languages (C++ and Python are no exception). Good bindings also need good decisions put in place by developers, generally speaking.