Null pointers instead of None in 5.25.02?

ROOT
1

Hi,

I used to get a None object when trying to access a non-existing object from a file. Instead, in version 5.25.02 I get a null pointer:

>>> f.Get('RunInfo') <ROOT.TObject object at 0x(nil)>

and I cannot anything with the object without getting
ReferenceError: attempt to access a null-pointer

Is there a way to handle such guys or this was changed in newer versions?

Thanks,
Bruno

2

Bruno,

what do you want to do with a null pointer (AFAIK you get the error only if you call one of the member functions)? Same thing as with None, it is only useful in predicates?

Null pointers have been given types in order for overloads based on them to work properly. E.g.:CallMyFunc( f.Get('RunInfo') )now works as expected.

Cheers,
Wim

3

Hi Wim,

Sorry if it was not clear. I just need something to replace:

[code]if f.Get(‘RunInfo’) is None:

do something

[/code]

The only (dirty) way I could find up to now was to call a class member and get the ReferenceError.

Cheers,
Bruno

4

Bruno,

that’s a FAQ … Never, ever do “is None” in a predicate unless you really need it to be None and nothing else (is in the python coding standards). Always do:[code]if not f.Get(‘RunInfo’):

do something[/code]Note that ‘== None’ would work as well (but is not recommended either).

Cheers,
Wim

5

Wim,

Right, I missed the simplest one. I was afraid that this comparison could be true for other objects such as empty lists.

http://www.python.org/dev/peps/pep-0290/#testing-for-none actually suggests “is” instead of “==”, although in my case it makes no difference.

Thanks,
Bruno

6

Bruno,

yes, if what you need is “Testing for None” (as per that PEP, i.e. if it needs to be None and nothing but None), then ‘is None’ is the way to go. For example, if None is a default value for a function argument and the code needs to figure out whether that value was changed.

Cheers,
Wim

7

Hi Wim:

Unfortunately the fact was that in older PyROOT versions the return value in these cases was None, and so testing ‘x is None’ was perfectly sensible. Changing from None to something else (though I understand the reason) is an API change which can introduce subtle bugs. Now I get to spend the afternoon looking through the ATLAS DQ code to make sure we don’t trigger it…

Cheers,
Peter

8

Peter,

yes, but only for return values of functions: it has never been true across the board that Python None is C++ NULL as the semantics of the two are way too different.

Sorry you have to do the work.

Cheers,
Wim