Python C API: omitted variable assignment causes unexpected behaviour
up vote
5
down vote
favorite
While using python with pyroot (a python interface to a CERN data analysis package named ROOT), I encountered the following strange behaviour:
print ROOT.TFile(fname).GetListOfKeys()
outputs None while the seemingly semantically equivalent code
f=ROOT.TFile(fname)
print f.GetListOfKeys()
outputs the expected <ROOT.THashList object ("THashList") at 0x13f0fa0>.
While this is hardly the first bug I have encountered while working with ROOT, this time I am quite puzzled that python allows this bug to happen.
I reckon that somehow, the reference count for the TFile object gets wrong in the first example, and that it gets deleted before GetListOfKeys is actually called. (After setting ROOT.TFile.__del__ to be some print command, this is indeed what happens.)
The way I see it, after ROOT.TFile(fname) gets executed, but before GetListOfKeys() is called, the pointer to the TFile object is on the stack. Therefore, the reference count should not be zero and the destructor should not be called until GetListOfKeys() returns.
Can anyone shed some light on why this happens?
On a related note, is there a way to disable python from ever deling my objects implicitly just because the reference count becomes zero? I tried gc.disable(), and it did not change the results. Is there any more elegant solution than appending the objects to some globally defined write-only list?
python python-2.7 root-framework pyroot
edited Nov 20 at 12:17
pseyfert
7901624
asked Aug 25 '14 at 13:38
user2247306
934
add a comment |
up vote
5
down vote
favorite
While using python with pyroot (a python interface to a CERN data analysis package named ROOT), I encountered the following strange behaviour:
print ROOT.TFile(fname).GetListOfKeys()
outputs None while the seemingly semantically equivalent code
f=ROOT.TFile(fname)
print f.GetListOfKeys()
outputs the expected <ROOT.THashList object ("THashList") at 0x13f0fa0>.
While this is hardly the first bug I have encountered while working with ROOT, this time I am quite puzzled that python allows this bug to happen.
I reckon that somehow, the reference count for the TFile object gets wrong in the first example, and that it gets deleted before GetListOfKeys is actually called. (After setting ROOT.TFile.__del__ to be some print command, this is indeed what happens.)
The way I see it, after ROOT.TFile(fname) gets executed, but before GetListOfKeys() is called, the pointer to the TFile object is on the stack. Therefore, the reference count should not be zero and the destructor should not be called until GetListOfKeys() returns.
Can anyone shed some light on why this happens?
On a related note, is there a way to disable python from ever deling my objects implicitly just because the reference count becomes zero? I tried gc.disable(), and it did not change the results. Is there any more elegant solution than appending the objects to some globally defined write-only list?
python python-2.7 root-framework pyroot
edited Nov 20 at 12:17
pseyfert
7901624
asked Aug 25 '14 at 13:38
user2247306
934
1
Which version of PyROOT are you using? Does an other version exhibits the same behavior?
– Sylvain Leroux
Aug 25 '14 at 13:56
Are you sure that theROOT.TFile(fname)object isn't being deleted afterGetListofKeysis called, but before the result of that call isprinted?
– Mark Dickinson
Aug 25 '14 at 14:38
@Sylvain Leroux: I am using ROOT 5.34/07. I do not have another version at our site, but I will try to test it.
– user2247306
Aug 28 '14 at 9:15
@Mark Dickinson: That is another possibility, which makes more sense. Thanks.
– user2247306
Aug 28 '14 at 9:18
add a comment |
up vote
5
down vote
favorite
up vote
5
down vote
favorite
While using python with pyroot (a python interface to a CERN data analysis package named ROOT), I encountered the following strange behaviour:
print ROOT.TFile(fname).GetListOfKeys()
outputs None while the seemingly semantically equivalent code
f=ROOT.TFile(fname)
print f.GetListOfKeys()
outputs the expected <ROOT.THashList object ("THashList") at 0x13f0fa0>.
While this is hardly the first bug I have encountered while working with ROOT, this time I am quite puzzled that python allows this bug to happen.
I reckon that somehow, the reference count for the TFile object gets wrong in the first example, and that it gets deleted before GetListOfKeys is actually called. (After setting ROOT.TFile.__del__ to be some print command, this is indeed what happens.)
The way I see it, after ROOT.TFile(fname) gets executed, but before GetListOfKeys() is called, the pointer to the TFile object is on the stack. Therefore, the reference count should not be zero and the destructor should not be called until GetListOfKeys() returns.
Can anyone shed some light on why this happens?
On a related note, is there a way to disable python from ever deling my objects implicitly just because the reference count becomes zero? I tried gc.disable(), and it did not change the results. Is there any more elegant solution than appending the objects to some globally defined write-only list?
python python-2.7 root-framework pyroot
edited Nov 20 at 12:17
pseyfert
7901624
asked Aug 25 '14 at 13:38
user2247306
934
While using python with pyroot (a python interface to a CERN data analysis package named ROOT), I encountered the following strange behaviour:
print ROOT.TFile(fname).GetListOfKeys()
outputs None while the seemingly semantically equivalent code
f=ROOT.TFile(fname)
print f.GetListOfKeys()
outputs the expected <ROOT.THashList object ("THashList") at 0x13f0fa0>.
While this is hardly the first bug I have encountered while working with ROOT, this time I am quite puzzled that python allows this bug to happen.
I reckon that somehow, the reference count for the TFile object gets wrong in the first example, and that it gets deleted before GetListOfKeys is actually called. (After setting ROOT.TFile.__del__ to be some print command, this is indeed what happens.)
The way I see it, after ROOT.TFile(fname) gets executed, but before GetListOfKeys() is called, the pointer to the TFile object is on the stack. Therefore, the reference count should not be zero and the destructor should not be called until GetListOfKeys() returns.
Can anyone shed some light on why this happens?
On a related note, is there a way to disable python from ever deling my objects implicitly just because the reference count becomes zero? I tried gc.disable(), and it did not change the results. Is there any more elegant solution than appending the objects to some globally defined write-only list?
python python-2.7 root-framework pyroot
python python-2.7 root-framework pyroot
edited Nov 20 at 12:17
pseyfert
7901624
asked Aug 25 '14 at 13:38
user2247306
934
edited Nov 20 at 12:17
pseyfert
7901624
asked Aug 25 '14 at 13:38
user2247306
934
edited Nov 20 at 12:17
pseyfert
7901624
edited Nov 20 at 12:17
pseyfert
7901624
edited Nov 20 at 12:17
pseyfert
7901624
7901624
asked Aug 25 '14 at 13:38
user2247306
934
asked Aug 25 '14 at 13:38
user2247306
934
asked Aug 25 '14 at 13:38
user2247306
934
934
1
Which version of PyROOT are you using? Does an other version exhibits the same behavior?
– Sylvain Leroux
Aug 25 '14 at 13:56
Are you sure that theROOT.TFile(fname)object isn't being deleted afterGetListofKeysis called, but before the result of that call isprinted?
– Mark Dickinson
Aug 25 '14 at 14:38
@Sylvain Leroux: I am using ROOT 5.34/07. I do not have another version at our site, but I will try to test it.
– user2247306
Aug 28 '14 at 9:15
@Mark Dickinson: That is another possibility, which makes more sense. Thanks.
– user2247306
Aug 28 '14 at 9:18
add a comment |
1
Which version of PyROOT are you using? Does an other version exhibits the same behavior?
– Sylvain Leroux
Aug 25 '14 at 13:56
Are you sure that theROOT.TFile(fname)object isn't being deleted afterGetListofKeysis called, but before the result of that call isprinted?
– Mark Dickinson
Aug 25 '14 at 14:38
@Sylvain Leroux: I am using ROOT 5.34/07. I do not have another version at our site, but I will try to test it.
– user2247306
Aug 28 '14 at 9:15
@Mark Dickinson: That is another possibility, which makes more sense. Thanks.
– user2247306
Aug 28 '14 at 9:18
1
1
Which version of PyROOT are you using? Does an other version exhibits the same behavior?
– Sylvain Leroux
Aug 25 '14 at 13:56
Which version of PyROOT are you using? Does an other version exhibits the same behavior?
– Sylvain Leroux
Aug 25 '14 at 13:56
Are you sure that the
ROOT.TFile(fname) object isn't being deleted after GetListofKeys is called, but before the result of that call is printed?– Mark Dickinson
Aug 25 '14 at 14:38
Are you sure that the
ROOT.TFile(fname) object isn't being deleted after GetListofKeys is called, but before the result of that call is printed?– Mark Dickinson
Aug 25 '14 at 14:38
@Sylvain Leroux: I am using ROOT 5.34/07. I do not have another version at our site, but I will try to test it.
– user2247306
Aug 28 '14 at 9:15
@Sylvain Leroux: I am using ROOT 5.34/07. I do not have another version at our site, but I will try to test it.
– user2247306
Aug 28 '14 at 9:15
@Mark Dickinson: That is another possibility, which makes more sense. Thanks.
– user2247306
Aug 28 '14 at 9:18
@Mark Dickinson: That is another possibility, which makes more sense. Thanks.
– user2247306
Aug 28 '14 at 9:18
add a comment |
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f25487199%2fpython-c-api-omitted-variable-assignment-causes-unexpected-behaviour%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f25487199%2fpython-c-api-omitted-variable-assignment-causes-unexpected-behaviour%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Which version of PyROOT are you using? Does an other version exhibits the same behavior?
– Sylvain Leroux
Aug 25 '14 at 13:56
Are you sure that the
ROOT.TFile(fname)object isn't being deleted afterGetListofKeysis called, but before the result of that call isprinted?– Mark Dickinson
Aug 25 '14 at 14:38
@Sylvain Leroux: I am using ROOT 5.34/07. I do not have another version at our site, but I will try to test it.
– user2247306
Aug 28 '14 at 9:15
@Mark Dickinson: That is another possibility, which makes more sense. Thanks.
– user2247306
Aug 28 '14 at 9:18