Auto compute __all__ to only use explicitly defined import











up vote
0
down vote

favorite












I have an __init__ file in a folder foo/ which import some modules



from a import ClassA
from b import *

__all__ = [s for s in dir() if not s.startswith('_')]


My folder foo/ contains additional .py files



foo/
a.py # Contain ClassA
b.py # Contain ClassB
c.py


a import c, so when I import a, it automatically import c and add it to the locals() scope of the __init__, even if c isn't imported in __init__.



I would like the __all__ of my init file to only contains the imports that I explicitly declared in the files (so just ClassA and ClassB). However, c, even if not imported in the __init__ is automatically added.



How can I dynamically compute __all__ to only contains the imports that I explicitly define in my __init__.py. Both locals() or dir() also return other files from the module foo.



Ideally, the solution should be both Py2.7 Py3 compatible.










share|improve this question




















  • 2




    Could not reproduce this - with this file structure and imports, dir() should not include c. Either way, __all__ is not mandatory, and in this case omitting it will yield the result you want.
    – roeen30
    Nov 10 at 22:57










  • At least classes and functions carry a __module__ attribute which identifies the module of their definition. You may need to filter which items really come from the desired modules.
    – Michael Butscher
    Nov 10 at 23:02










  • @roeen30 I've run more test, so it seems that because a import c, c gets automatically added to dir() even if I haven't explicitly imported it. I updated the question. Also in this case I really need the __all__ as it is used by an external program I don't control.
    – Conchylicultor
    Nov 10 at 23:58








  • 1




    To check for directly vs. indirectly imported modules you may have to parse the file.
    – Michael Butscher
    Nov 11 at 0:30















up vote
0
down vote

favorite












I have an __init__ file in a folder foo/ which import some modules



from a import ClassA
from b import *

__all__ = [s for s in dir() if not s.startswith('_')]


My folder foo/ contains additional .py files



foo/
a.py # Contain ClassA
b.py # Contain ClassB
c.py


a import c, so when I import a, it automatically import c and add it to the locals() scope of the __init__, even if c isn't imported in __init__.



I would like the __all__ of my init file to only contains the imports that I explicitly declared in the files (so just ClassA and ClassB). However, c, even if not imported in the __init__ is automatically added.



How can I dynamically compute __all__ to only contains the imports that I explicitly define in my __init__.py. Both locals() or dir() also return other files from the module foo.



Ideally, the solution should be both Py2.7 Py3 compatible.










share|improve this question




















  • 2




    Could not reproduce this - with this file structure and imports, dir() should not include c. Either way, __all__ is not mandatory, and in this case omitting it will yield the result you want.
    – roeen30
    Nov 10 at 22:57










  • At least classes and functions carry a __module__ attribute which identifies the module of their definition. You may need to filter which items really come from the desired modules.
    – Michael Butscher
    Nov 10 at 23:02










  • @roeen30 I've run more test, so it seems that because a import c, c gets automatically added to dir() even if I haven't explicitly imported it. I updated the question. Also in this case I really need the __all__ as it is used by an external program I don't control.
    – Conchylicultor
    Nov 10 at 23:58








  • 1




    To check for directly vs. indirectly imported modules you may have to parse the file.
    – Michael Butscher
    Nov 11 at 0:30













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I have an __init__ file in a folder foo/ which import some modules



from a import ClassA
from b import *

__all__ = [s for s in dir() if not s.startswith('_')]


My folder foo/ contains additional .py files



foo/
a.py # Contain ClassA
b.py # Contain ClassB
c.py


a import c, so when I import a, it automatically import c and add it to the locals() scope of the __init__, even if c isn't imported in __init__.



I would like the __all__ of my init file to only contains the imports that I explicitly declared in the files (so just ClassA and ClassB). However, c, even if not imported in the __init__ is automatically added.



How can I dynamically compute __all__ to only contains the imports that I explicitly define in my __init__.py. Both locals() or dir() also return other files from the module foo.



Ideally, the solution should be both Py2.7 Py3 compatible.










share|improve this question















I have an __init__ file in a folder foo/ which import some modules



from a import ClassA
from b import *

__all__ = [s for s in dir() if not s.startswith('_')]


My folder foo/ contains additional .py files



foo/
a.py # Contain ClassA
b.py # Contain ClassB
c.py


a import c, so when I import a, it automatically import c and add it to the locals() scope of the __init__, even if c isn't imported in __init__.



I would like the __all__ of my init file to only contains the imports that I explicitly declared in the files (so just ClassA and ClassB). However, c, even if not imported in the __init__ is automatically added.



How can I dynamically compute __all__ to only contains the imports that I explicitly define in my __init__.py. Both locals() or dir() also return other files from the module foo.



Ideally, the solution should be both Py2.7 Py3 compatible.







python






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 11 at 8:38

























asked Nov 10 at 22:51









Conchylicultor

1,0541222




1,0541222








  • 2




    Could not reproduce this - with this file structure and imports, dir() should not include c. Either way, __all__ is not mandatory, and in this case omitting it will yield the result you want.
    – roeen30
    Nov 10 at 22:57










  • At least classes and functions carry a __module__ attribute which identifies the module of their definition. You may need to filter which items really come from the desired modules.
    – Michael Butscher
    Nov 10 at 23:02










  • @roeen30 I've run more test, so it seems that because a import c, c gets automatically added to dir() even if I haven't explicitly imported it. I updated the question. Also in this case I really need the __all__ as it is used by an external program I don't control.
    – Conchylicultor
    Nov 10 at 23:58








  • 1




    To check for directly vs. indirectly imported modules you may have to parse the file.
    – Michael Butscher
    Nov 11 at 0:30














  • 2




    Could not reproduce this - with this file structure and imports, dir() should not include c. Either way, __all__ is not mandatory, and in this case omitting it will yield the result you want.
    – roeen30
    Nov 10 at 22:57










  • At least classes and functions carry a __module__ attribute which identifies the module of their definition. You may need to filter which items really come from the desired modules.
    – Michael Butscher
    Nov 10 at 23:02










  • @roeen30 I've run more test, so it seems that because a import c, c gets automatically added to dir() even if I haven't explicitly imported it. I updated the question. Also in this case I really need the __all__ as it is used by an external program I don't control.
    – Conchylicultor
    Nov 10 at 23:58








  • 1




    To check for directly vs. indirectly imported modules you may have to parse the file.
    – Michael Butscher
    Nov 11 at 0:30








2




2




Could not reproduce this - with this file structure and imports, dir() should not include c. Either way, __all__ is not mandatory, and in this case omitting it will yield the result you want.
– roeen30
Nov 10 at 22:57




Could not reproduce this - with this file structure and imports, dir() should not include c. Either way, __all__ is not mandatory, and in this case omitting it will yield the result you want.
– roeen30
Nov 10 at 22:57












At least classes and functions carry a __module__ attribute which identifies the module of their definition. You may need to filter which items really come from the desired modules.
– Michael Butscher
Nov 10 at 23:02




At least classes and functions carry a __module__ attribute which identifies the module of their definition. You may need to filter which items really come from the desired modules.
– Michael Butscher
Nov 10 at 23:02












@roeen30 I've run more test, so it seems that because a import c, c gets automatically added to dir() even if I haven't explicitly imported it. I updated the question. Also in this case I really need the __all__ as it is used by an external program I don't control.
– Conchylicultor
Nov 10 at 23:58






@roeen30 I've run more test, so it seems that because a import c, c gets automatically added to dir() even if I haven't explicitly imported it. I updated the question. Also in this case I really need the __all__ as it is used by an external program I don't control.
– Conchylicultor
Nov 10 at 23:58






1




1




To check for directly vs. indirectly imported modules you may have to parse the file.
– Michael Butscher
Nov 11 at 0:30




To check for directly vs. indirectly imported modules you may have to parse the file.
– Michael Butscher
Nov 11 at 0:30












1 Answer
1






active

oldest

votes

















up vote
1
down vote













Of course foo.c will show up in foos locals() once it is imported, that's how python imports work. __all__ is there to allow you to control what from foo import * does, by explicitly listing what should be imported.



So if you want from foo import * to import a and b, your __init__.py only needs to contain:



__all__ = ['a', 'b']


You don't need to import the submodules before that at all, only if you want to add code to your __init__.py that uses them.



So if you want to avoid the redundancy of having to import and add the submodules to __all__, just drop the imports and use __all__ explicitly.






share|improve this answer





















  • I know I can manually set __all__, but the question is about dynamically computing __all__. In practice, my imports are not just import a but from a import MyClass, from b import *, so just using __all__ won't work. I updated the question
    – Conchylicultor
    Nov 11 at 8:35












  • After importing stuff at package level there's not really any way to decide wheather a submodule was imported directly or indiretctly by some other submodule. Like @MichaelButscher said above, you'd have to parse the file to do so. Or try something like the decorator suggested here to mark what you want exported. Which seems a lot of work to support star imports which are regarded as bad parctice by many...
    – mata
    Nov 13 at 21:42













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
});


}
});














 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53244205%2fauto-compute-all-to-only-use-explicitly-defined-import%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








up vote
1
down vote













Of course foo.c will show up in foos locals() once it is imported, that's how python imports work. __all__ is there to allow you to control what from foo import * does, by explicitly listing what should be imported.



So if you want from foo import * to import a and b, your __init__.py only needs to contain:



__all__ = ['a', 'b']


You don't need to import the submodules before that at all, only if you want to add code to your __init__.py that uses them.



So if you want to avoid the redundancy of having to import and add the submodules to __all__, just drop the imports and use __all__ explicitly.






share|improve this answer





















  • I know I can manually set __all__, but the question is about dynamically computing __all__. In practice, my imports are not just import a but from a import MyClass, from b import *, so just using __all__ won't work. I updated the question
    – Conchylicultor
    Nov 11 at 8:35












  • After importing stuff at package level there's not really any way to decide wheather a submodule was imported directly or indiretctly by some other submodule. Like @MichaelButscher said above, you'd have to parse the file to do so. Or try something like the decorator suggested here to mark what you want exported. Which seems a lot of work to support star imports which are regarded as bad parctice by many...
    – mata
    Nov 13 at 21:42

















up vote
1
down vote













Of course foo.c will show up in foos locals() once it is imported, that's how python imports work. __all__ is there to allow you to control what from foo import * does, by explicitly listing what should be imported.



So if you want from foo import * to import a and b, your __init__.py only needs to contain:



__all__ = ['a', 'b']


You don't need to import the submodules before that at all, only if you want to add code to your __init__.py that uses them.



So if you want to avoid the redundancy of having to import and add the submodules to __all__, just drop the imports and use __all__ explicitly.






share|improve this answer





















  • I know I can manually set __all__, but the question is about dynamically computing __all__. In practice, my imports are not just import a but from a import MyClass, from b import *, so just using __all__ won't work. I updated the question
    – Conchylicultor
    Nov 11 at 8:35












  • After importing stuff at package level there's not really any way to decide wheather a submodule was imported directly or indiretctly by some other submodule. Like @MichaelButscher said above, you'd have to parse the file to do so. Or try something like the decorator suggested here to mark what you want exported. Which seems a lot of work to support star imports which are regarded as bad parctice by many...
    – mata
    Nov 13 at 21:42















up vote
1
down vote










up vote
1
down vote









Of course foo.c will show up in foos locals() once it is imported, that's how python imports work. __all__ is there to allow you to control what from foo import * does, by explicitly listing what should be imported.



So if you want from foo import * to import a and b, your __init__.py only needs to contain:



__all__ = ['a', 'b']


You don't need to import the submodules before that at all, only if you want to add code to your __init__.py that uses them.



So if you want to avoid the redundancy of having to import and add the submodules to __all__, just drop the imports and use __all__ explicitly.






share|improve this answer












Of course foo.c will show up in foos locals() once it is imported, that's how python imports work. __all__ is there to allow you to control what from foo import * does, by explicitly listing what should be imported.



So if you want from foo import * to import a and b, your __init__.py only needs to contain:



__all__ = ['a', 'b']


You don't need to import the submodules before that at all, only if you want to add code to your __init__.py that uses them.



So if you want to avoid the redundancy of having to import and add the submodules to __all__, just drop the imports and use __all__ explicitly.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 11 at 1:24









mata

47.8k7100123




47.8k7100123












  • I know I can manually set __all__, but the question is about dynamically computing __all__. In practice, my imports are not just import a but from a import MyClass, from b import *, so just using __all__ won't work. I updated the question
    – Conchylicultor
    Nov 11 at 8:35












  • After importing stuff at package level there's not really any way to decide wheather a submodule was imported directly or indiretctly by some other submodule. Like @MichaelButscher said above, you'd have to parse the file to do so. Or try something like the decorator suggested here to mark what you want exported. Which seems a lot of work to support star imports which are regarded as bad parctice by many...
    – mata
    Nov 13 at 21:42




















  • I know I can manually set __all__, but the question is about dynamically computing __all__. In practice, my imports are not just import a but from a import MyClass, from b import *, so just using __all__ won't work. I updated the question
    – Conchylicultor
    Nov 11 at 8:35












  • After importing stuff at package level there's not really any way to decide wheather a submodule was imported directly or indiretctly by some other submodule. Like @MichaelButscher said above, you'd have to parse the file to do so. Or try something like the decorator suggested here to mark what you want exported. Which seems a lot of work to support star imports which are regarded as bad parctice by many...
    – mata
    Nov 13 at 21:42


















I know I can manually set __all__, but the question is about dynamically computing __all__. In practice, my imports are not just import a but from a import MyClass, from b import *, so just using __all__ won't work. I updated the question
– Conchylicultor
Nov 11 at 8:35






I know I can manually set __all__, but the question is about dynamically computing __all__. In practice, my imports are not just import a but from a import MyClass, from b import *, so just using __all__ won't work. I updated the question
– Conchylicultor
Nov 11 at 8:35














After importing stuff at package level there's not really any way to decide wheather a submodule was imported directly or indiretctly by some other submodule. Like @MichaelButscher said above, you'd have to parse the file to do so. Or try something like the decorator suggested here to mark what you want exported. Which seems a lot of work to support star imports which are regarded as bad parctice by many...
– mata
Nov 13 at 21:42






After importing stuff at package level there's not really any way to decide wheather a submodule was imported directly or indiretctly by some other submodule. Like @MichaelButscher said above, you'd have to parse the file to do so. Or try something like the decorator suggested here to mark what you want exported. Which seems a lot of work to support star imports which are regarded as bad parctice by many...
– mata
Nov 13 at 21:42




















 

draft saved


draft discarded



















































 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53244205%2fauto-compute-all-to-only-use-explicitly-defined-import%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

Xamarin.iOS Cant Deploy on Iphone

Glorious Revolution

Dulmage-Mendelsohn matrix decomposition in Python