I have a module like this:
module Model where
import FlowType
.
.
.
I am using FlowType in Model's body, but I want also to export along with Model's functions FlowType's too. I found a module with the following syntax:
module Import
( module Import
) where
import Foundation as Import
.
.
.
What is this module Import ( module Import) where???
How can I do the same in my Model module (and also exporting its own functions)?
Suppose the module Foundation exports the names foo and bar.
First, import Foundation as Import makes those names available as Import.foo and Import.bar inside the module currently being defined.
The module statement then exports those names as well. Instead of having to write
module Import (foo, bar) where
you can export everything accessible via the name Import with the syntax in the question. The example is a little confusing since it uses Import both as the internal name for Foundation and as the name of the current module. It would be more obvious written as
module Import (module Foundation) where
import Foundation
.
.
.
In your case, you would write
module Model (module FlowType) where
import FlowType
to export everything imported from FlowType from your module.
Related
this is such a simple problem but I cant seem to find any direct explanation to this.
in module.py
def foo():
print("foo")
in main.py
import module
foo()
it will result in an error saying that foo is not defined? when i look for the answer online, I can't find anything surprisingly
I'm not planning to use things like
from x import y
just straight up the import system
When you import an external module, it generates a variable named module that contains all classes, functions and variables from the module. To acess 'foo' function you need to first acess the module:
module.foo()
To import 'foo' function you can import everything from the module, like this:
from module import *
Now you can simply do: foo()
You can also set a custom name to the module, like:
import module as M
And now you can run 'foo' like this:
M.foo()
PS: I'm not english native
The statement
import module
makes the name of module module available. So you can use module.foo().
If you want to call foo() without "qualifying" it:
from module import foo
or
from module import *
but that latter is bad idea because you are liable to import unexpected names, which may collide with other names you imported from other modules.
from model import foo
is the preferred way as in any kinds of
from model import *
you (and anyone ever working on that code) has no idea what has been imported. Could even lead to name conflicts.
I am reading the source code at "Type definitions for Express 4.16" and found this funny line (#18):
import serveStatic = require("serve-static");
Since import is the new way to work with modules in ES6, why above code is used or needed at all?
Type definitions for Express 4.16 is written(index.d.ts) in typescript, Where import = require() is a TypeScript Syntax
TypeScript - Modules (export = and import = require())
The export = syntax specifies a single object that is exported from the module. This can be a class, interface, namespace, function, or enum.
When exporting a module using export =, TypeScript-specific import module = require("module") must be used to import the module.
Reference : Modules
I would like to make an imported module behave like an object, ie. an dictionary.
E.g.
import module
print(module['key'])
and in module.py
return {'key':'access'}
This is very easy for Class by inheriting from dict, but how do I do this on a module level?
In particular I want to dynamically built the dictionary in module and return it when module is imported.
I know that there are other solutions such as defining the dict as a var in the module workspace and accessing it via module.var, but I am interested if something like this is possible.
As you point out, you can do this with a class, but not with a module, as modules are not subscriptable.Now I'm not going to ask why you want to do this with an import, but it can be done.
What you do is create a class that does what you want, and then have the module replace itself with the class when imported. This is of course a 'bit of a hack' (tm). Here I'm using UserDict as it gives easy access to the dict via the class attr data, but you could do anything you like in this class:
# module.py
from collections import UserDict
import sys
import types
class ModuleDict(types.ModuleType, UserDict):
data = {'key': 'access}
sys.modules[__name__] = ModuleDict(__name__)
Then you can import the module and use it as desired:
# code.py
import module
print(module['key']
# access
Given this simple folder structure
/main.py
/project/a.py
/project/b.py
main.py is executed by the python interpreter and contains a single line, import project.a.
a and b are modules, they need to import each other. A way to achieve this would be
import project.[a|b]
When working with deeper nested folder structures you don't want to write the entire path everytime you use a module e.g.
import project.foo.bar
project.foo.bar.set_flag(project.foo.bar.SUPER)
Both from project import [a|b] and import project.[a|b] as [a|b] result in an import error (when used in both, a and b).
What is different between the standart import syntax and the from or as syntax? Why is only the standart syntax working for mutual imports?
And more importantly, is there a simple and clean way to import modules that allows mutual imports and assigning shorter names to them (ideally the modules basename e.g. bar in the case of project.foo.bar)?
When you do either import project.a or from project import a, the following happens:
The module object for project.a is placed into sys.modules. This is a dictionary that maps each module name to its module object, so you'll have sys.modules = {..., 'p.a': <module 'p.a' from '.../project/a.py'>, ...}.
The code for the module is executed.
The a attribute is added to project.
Now, here is the difference between import project.a and from project import a:
import project.a just looks for sys.modules['project.a']. If it exists, it binds the name project using sys.modules['project'].
from project import a looks for sys.modules['project'] and then checks if the project module has an a attribute.
You can think of from project import a as an equivalent to the following two lines:
import project.a # not problematic
a = project.a # causes an error
That why you are seeing an exception only when doing from project import a: sys.modules['project.a'] exists, but project does not yet have a a attribute.
The quickest solution would be to simply avoid circular imports. But if you can't, then the usual strategies are:
Import as late as possible. Suppose that your a.py looks like this:
from project import b
def something():
return b.something_else()
Rewrite it as follows:
def something():
from project import b
return b.something_else()
Of course, you would have to repeat imports in all your functions.
Use lazy imports. Lazy imports are not standard feature of Python, but you can find many implementations around. They work by using the "import as late as possible" principle, but they add some syntactic sugar to let you write fewer code.
Cheat, and use sys.modules, like this:
import sys
import project.a
a = sys.modules['project.a']
Very un-pythonic, but works.
Obviously, whatever solution you choose, you won't be able to access the attributes from a or b until the modules have been fully loaded.
The scaffolded site in Yesod generates an Import.hs file which contains the following.
module Import
( module Import
) where
import Prelude as Import
import Yesod as Import
-- ...
What is this pattern for? My understanding is that it exports everything from the modules imported in the Import.hs package, but wouldn't just module Import where do the same thing? What is the meaning of the nested module keyword inside the module Import (module Import) where ...?
In the Haskell language report exporting a module is described as:
The form “module M” names the set of all entities that are in scope with both an unqualified name “e” and a qualified name “M.e”. This set may be empty.
§5.2 Export Lists
An export list identifies the entities to be exported by a module declaration. A module implementation may only export an entity that it declares, or that it imports from some other module. If the export list is omitted, all values, types and classes defined in the module are exported, but not those that are imported.
Entities in an export list may be named as follows:
...
The form “module M” names the set of all entities that are in scope with both an unqualified name “e” and a qualified name “M.e”. This set may be empty.
It means that the semantic of:
module Import
( module Import
) where
import Prelude as Import
import Yesod as Import
-- ...
is to take all that is contained in Prelude and Yesod modules and export it.
What you propose instead:
module Import where
would not export what's imported by Prelude and Yesod, as per quote above:
If the export list is omitted, all values, types and classes defined in the module are exported, but not those that are imported.