importing only some parts of a large library, but hiding the library structure for convenience
Please look at the example. Is it possible to achieve this?
# 1. importing from a large package lpack
# only those parts that are going to be used
from lpack import timers # defines SomeTimer and other Timers
from lpack import triggers # defines RegularTrigger and others Triggers
# not importing many many other lpack modules
# 2. in the *same .py file* not having to care
# about the internal organization of the lpack
mytimer = lpack.SomeTimer() # i.e. not timers.SomeTimer()
mytrigger = lpack.RegularTrigger()
I have no solution. My idea is something like lpack = timers + triggers
(not literally, of course). An automated way (some kind of desired import side effect) would be the best.
python python-import
add a comment |
Please look at the example. Is it possible to achieve this?
# 1. importing from a large package lpack
# only those parts that are going to be used
from lpack import timers # defines SomeTimer and other Timers
from lpack import triggers # defines RegularTrigger and others Triggers
# not importing many many other lpack modules
# 2. in the *same .py file* not having to care
# about the internal organization of the lpack
mytimer = lpack.SomeTimer() # i.e. not timers.SomeTimer()
mytrigger = lpack.RegularTrigger()
I have no solution. My idea is something like lpack = timers + triggers
(not literally, of course). An automated way (some kind of desired import side effect) would be the best.
python python-import
You can monkeypatchlpack
after theimport
s with statements likelpack.SomeTimer = timers.SomeTimer
.
– martineau
Nov 21 '18 at 9:09
add a comment |
Please look at the example. Is it possible to achieve this?
# 1. importing from a large package lpack
# only those parts that are going to be used
from lpack import timers # defines SomeTimer and other Timers
from lpack import triggers # defines RegularTrigger and others Triggers
# not importing many many other lpack modules
# 2. in the *same .py file* not having to care
# about the internal organization of the lpack
mytimer = lpack.SomeTimer() # i.e. not timers.SomeTimer()
mytrigger = lpack.RegularTrigger()
I have no solution. My idea is something like lpack = timers + triggers
(not literally, of course). An automated way (some kind of desired import side effect) would be the best.
python python-import
Please look at the example. Is it possible to achieve this?
# 1. importing from a large package lpack
# only those parts that are going to be used
from lpack import timers # defines SomeTimer and other Timers
from lpack import triggers # defines RegularTrigger and others Triggers
# not importing many many other lpack modules
# 2. in the *same .py file* not having to care
# about the internal organization of the lpack
mytimer = lpack.SomeTimer() # i.e. not timers.SomeTimer()
mytrigger = lpack.RegularTrigger()
I have no solution. My idea is something like lpack = timers + triggers
(not literally, of course). An automated way (some kind of desired import side effect) would be the best.
python python-import
python python-import
asked Nov 21 '18 at 8:47
VPfBVPfB
4,42211230
4,42211230
You can monkeypatchlpack
after theimport
s with statements likelpack.SomeTimer = timers.SomeTimer
.
– martineau
Nov 21 '18 at 9:09
add a comment |
You can monkeypatchlpack
after theimport
s with statements likelpack.SomeTimer = timers.SomeTimer
.
– martineau
Nov 21 '18 at 9:09
You can monkeypatch
lpack
after the import
s with statements like lpack.SomeTimer = timers.SomeTimer
.– martineau
Nov 21 '18 at 9:09
You can monkeypatch
lpack
after the import
s with statements like lpack.SomeTimer = timers.SomeTimer
.– martineau
Nov 21 '18 at 9:09
add a comment |
1 Answer
1
active
oldest
votes
How about this:
from lpack.timers import *
from lpack.triggers import *
mytimer = SomeTimer()
mytrigger = RegularTrigger()
The disadvantage is that if both packages contain methods with the same name one of them will be overwritten (I expect the second import to overwrite the first). You should also be careful not to have local methods with the same name, as this will lead to conflicts.
Yes, this way is the problem avoided, but it did not answer my question.
– VPfB
Nov 21 '18 at 9:18
add a comment |
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%2f53408217%2fimporting-only-some-parts-of-a-large-library-but-hiding-the-library-structure-f%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
How about this:
from lpack.timers import *
from lpack.triggers import *
mytimer = SomeTimer()
mytrigger = RegularTrigger()
The disadvantage is that if both packages contain methods with the same name one of them will be overwritten (I expect the second import to overwrite the first). You should also be careful not to have local methods with the same name, as this will lead to conflicts.
Yes, this way is the problem avoided, but it did not answer my question.
– VPfB
Nov 21 '18 at 9:18
add a comment |
How about this:
from lpack.timers import *
from lpack.triggers import *
mytimer = SomeTimer()
mytrigger = RegularTrigger()
The disadvantage is that if both packages contain methods with the same name one of them will be overwritten (I expect the second import to overwrite the first). You should also be careful not to have local methods with the same name, as this will lead to conflicts.
Yes, this way is the problem avoided, but it did not answer my question.
– VPfB
Nov 21 '18 at 9:18
add a comment |
How about this:
from lpack.timers import *
from lpack.triggers import *
mytimer = SomeTimer()
mytrigger = RegularTrigger()
The disadvantage is that if both packages contain methods with the same name one of them will be overwritten (I expect the second import to overwrite the first). You should also be careful not to have local methods with the same name, as this will lead to conflicts.
How about this:
from lpack.timers import *
from lpack.triggers import *
mytimer = SomeTimer()
mytrigger = RegularTrigger()
The disadvantage is that if both packages contain methods with the same name one of them will be overwritten (I expect the second import to overwrite the first). You should also be careful not to have local methods with the same name, as this will lead to conflicts.
answered Nov 21 '18 at 9:03
arudzinskaarudzinska
1,4561721
1,4561721
Yes, this way is the problem avoided, but it did not answer my question.
– VPfB
Nov 21 '18 at 9:18
add a comment |
Yes, this way is the problem avoided, but it did not answer my question.
– VPfB
Nov 21 '18 at 9:18
Yes, this way is the problem avoided, but it did not answer my question.
– VPfB
Nov 21 '18 at 9:18
Yes, this way is the problem avoided, but it did not answer my question.
– VPfB
Nov 21 '18 at 9:18
add a comment |
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%2f53408217%2fimporting-only-some-parts-of-a-large-library-but-hiding-the-library-structure-f%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
You can monkeypatch
lpack
after theimport
s with statements likelpack.SomeTimer = timers.SomeTimer
.– martineau
Nov 21 '18 at 9:09