You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Such that foo, foo.bar and foo.bar.Baz are not actually loaded at all.
It could 'import' the symbol as a forward-ref or some type machinery thing. (maybe just the string "Baz")
Alternatives:
from __future__ importannotationsfromtypingimportTYPE_CHECKINGifTYPE_CHECKING:
fromfoo.barimportBazdeffoo(baz: Baz):
print(baz.bat)
This is mega boilerplate, gross, and leads to messy wacky 'type-time' side effects (python/mypy#11503).
Would be nice to avoid needing to specify type for a collection of type-only imports.
Python named imports (from ... import ...) are analogous to TypeScript 'named' imports.
Python doesn't have an equivalent to TypeScript 'default' imports, so those can be ignored.
Python module imports (import ...) are analogous to TypeScript 'namespace' imports.
Python wildcard imports (from ... import *) don't have an analogue in TypeScript, but can be considered much the same as named imports for this purpose, I believe.
Current TypeScript import examples (restricted to syntax with appropriate Python analogue)
// region named importsimport{foo,bar}from"..."// value-only named importsimport{foo,bar}from"..."// as above, with 'rename'importtype{Foo,Bar}from"..."// type-only named importsimporttype{Foo: FooByAnotherName,Bar}from"..."// as above, with 'rename'import{typeFoo,typeBar}from"..."// type-only named imports, specified per-nameimport{typeFoo: FooByAnotherName,typeBar}from"..."// as above, with 'rename'import{foo,typeFoo}from"..."// mixed named imports, specified per-nameimport{fooasfooByAnotherName,typeFoo}from"..."// as above, with 'rename'// endregion// region namespace importsimport*asmodulefrom"..."// value namespace import with 'rename'importtype*asModulefrom"..."// type namespace import with 'rename'// endregion
Here's the Python syntax I propose, covering Python's various 'flavours' of import:
# region named importsfrom ... importfoo, bar# value-only named imports (unparenthesised)from ... importfooasfoo_by_another_name, bar# as above, with 'rename'from ... import (foo, bar) # value-only named imports (parenthesised)from ... import (fooasfoo_by_another_name, bar) # as above, with 'rename'from ... importtype (Foo, Bar) # type-only named imports (parenthesis required)from ... importtype (FooasFooByAnotherName, Bar) # as above, with 'rename'from ... importtypeFoo, typeBar# type-only named imports, specified per-name (unparenthesised)from ... importtypeFooasFooByAnotherName, typeBar# as above, with 'rename'from ... import (typeFoo, typeBar) # type-only named imports, specified per-name (parenthesised)from ... import (typeFooasFooByAnotherName, typeBar) # as above, with 'rename'from ... importfoo, typeFoo# mixed named imports, specified per-name (unparenthesised)from ... importfooasfoo_by_another_name, typeFoo# as above, with 'rename'from ... import (foo, typeFoo) # mixed named imports, specified per-name (parenthesised)from ... import (fooasfoo_by_another_name, typeFoo# as above, with 'rename'# endregion# region module importsimport ... # value module importimport ... asmodule# as above, with 'rename'import ..., ... # value multiple module importimport ... asmodule, ... # as above, with 'rename'import type ... # type module importimport type ... asModule# as above, with 'rename'import type ..., type ... # type multiple module importimporttype ... asModule, type ... # as above, with 'rename'# endregion# region wildcard importsfrom ... import*# value wildcard importfrom ... import type *# type wildcard import# endregion
An alternative to the 'parenthesis required' rule would be to use types vs type to distinguish between type-only and mixed imports. However, that would conflict with the existing types module, and I don't know enough about grammars/parsers to know whether that would break e.g. import types.
Activity
h-joo commentedon Oct 15, 2024
+1 to this feature, it would help the code to be much readable to the alternative that we have right now
Gobot1234 commentedon Oct 15, 2024
I was personally interested in this but if it gave you lazy imports so it'd still be introspectable
mkzeender commentedon Oct 29, 2024
An easy solution is to have
be syntactic sugar for
In other words, create a (generic) type alias whose
__value__is lazily resolved to the actual Baz class.Lordfirespeed commentedon Mar 6, 2025
Would be nice to avoid needing to specify
typefor a collection of type-only imports.Python named imports (
from ... import ...) are analogous to TypeScript 'named' imports.Python doesn't have an equivalent to TypeScript 'default' imports, so those can be ignored.
Python module imports (
import ...) are analogous to TypeScript 'namespace' imports.Python wildcard imports (
from ... import *) don't have an analogue in TypeScript, but can be considered much the same as named imports for this purpose, I believe.Current TypeScript import examples (restricted to syntax with appropriate Python analogue)
Here's the Python syntax I propose, covering Python's various 'flavours' of
import:Here's a modified
import_stmtgrammar that I think matches the above: https://gist.github.com/Lordfirespeed/8a8140d94007c45679a3701b90968c12An alternative to the 'parenthesis required' rule would be to use
typesvstypeto distinguish between type-only and mixed imports. However, that would conflict with the existingtypesmodule, and I don't know enough about grammars/parsers to know whether that would break e.g.import types.