when I try to TDirectory.GetDirectory() an unexisting directory, I’m returned a TDirectory object wrapped around a null pointer. I was expecting, instead, a result of “None”:
[code]Python 2.4.6 (#1, Jun 9 2009, 15:12:07)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-10)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
import ROOT
F = ROOT.TFile(“test.root”, “UPDATE”)
F.GetDirectory(“unexisting”)
<ROOT.TDirectory object at 0x(nil)>[/code]
This is ROOT version 5.24/00.
In ROOT 5.18/00 + python 2.4.3 this does not happen (None is returned instead).
Is this something wrong with my code?
nothing wrong with the code, just that it proved beneficial to keep on carrying the type of the null pointer onwards for subsequent overloading purposes, so that was changed in later releases.
Note that checking like before still works (although the Python coding guidelines clearly recommend against comparing anything directly to None):[code]>>> F.GetDirectory(“unexisting”) == None
True
which of course is False (the object on the left is a TDirectory, not None).
I’m not a python amateur enough to understand why your code works – it does anyway. Is there any other way to do that check directly?
Do you happen to have any reference on the reason why one should avoid comparing objects with None?
no, using “is None” is meant to mean that you absolutely want to distinguish between receiving None (as in e.g. a void return from a function) and something else. If however, as is the case here, the test is on the validity of the return (i.e. whether it represents “False”; C++ can’t return None per se), the proper coding would be:if not F.GetDirectory("Unexisting"): Point being that Python is dynamically typed and many objects can take the meaning of “False”, not just None (the not-object).
Here is the reference from python.org:[quote] Also, beware of writing “if x” when you really mean “if x is not None”
– e.g. when testing whether a variable or argument that defaults to
None was set to some other value. The other value might have a type
(such as a container) that could be false in a boolean context![/quote]
Having the comparison evaluate true when comparing against None is a convenience for those cases where the results from two functions are compared directly.
I just noticed that TDirectory.Get() and TDirectory.GetStyle() have the same behavior.
Which breaks quite a lot of my code.
Could you point me to a list of functions that have this behavior changed? or should I assume that all the functions returning an object now work this way?
yes, all functions that return SomeObject* will return a typed NULL when such is returned from C++. As said, the reason was to allow overloading on the return type to work as would be expected from C++.