Mixing
Python C API: omitted variable assignment causes unexpected behaviour
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 '18 at 12:17
pseyfert
8141724
asked Aug 25 '14 at 13:38
user2247306user2247306
934
add a comment |
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 '18 at 12:17
pseyfert
8141724
asked Aug 25 '14 at 13:38
user2247306user2247306
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 |
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 '18 at 12:17
pseyfert
8141724
asked Aug 25 '14 at 13:38
user2247306user2247306
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 '18 at 12:17
pseyfert
8141724
asked Aug 25 '14 at 13:38
user2247306user2247306
934
edited Nov 20 '18 at 12:17
pseyfert
8141724
asked Aug 25 '14 at 13:38
user2247306user2247306
934
edited Nov 20 '18 at 12:17
pseyfert
8141724
edited Nov 20 '18 at 12:17
pseyfert
8141724
edited Nov 20 '18 at 12:17
pseyfert
8141724
8141724
asked Aug 25 '14 at 13:38
user2247306user2247306
934
asked Aug 25 '14 at 13:38
user2247306user2247306
934
asked Aug 25 '14 at 13:38
user2247306user2247306
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 |
0
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',
autoActivateHeartbeat: false,
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
0
active
oldest
votes
0
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.
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