Comments (10)
I've started this on my package-support
branch
from mypy.
Summary of my changes:
- moved code into
mypy
package - renamed
mypy.py
todriver.py
to avoid conflict with the package name
Issues:
- It would be nicer if
driver.py
could be moved into the package and then invoked withpython3 -m mypy.driver
but this messes with the code that tries to locate the stubs - The tests are currently broken
- There are circular imports, and the only way I could get the generated python work was to use lots of ugly fully qualified names
I've bootstrapped it to the same branch of mypy-py
if you want to try it out.
from mypy.
Circular imports have been a problem earlier as well. Much of the code was ported from Alore, and Alore places few restrictions on circular imports.
Why can't we use things like from mypy import nodes
to keep the old look of the code?
Here are a few more potential ways of dealing with circular imports:
- If they only affect type signatures and casts, we can allow them and erase the related imports automatically,
since
type signatures are erased. For overloads, where we can't just erase them, we can generate fully qualified
names. This feelts hacky, though, and can break clients that expect the imported name to be there. - Automatically move circular imports to the bottom of the file, and rename references within
the file to use fully qualified names. I'm not sure how reliably the transformation can be done, though. - Refactor the code to not have circular imports. This probably involves at least moving more code to the nodes
module. Also type checking and transform related modules may have to be combined (though I guess this is
less problematic there, and it's easier to live with the fully qualified names).
from mypy.
I tried from mypy import nodes
initially but the essential difference is
the following:
from mypy import nodes
does thegetattr(mypy, 'nodes')
immediately
(doesn't work, sincemypy.nodes
doesn't exist until the circular import
has finished)import mypy.nodes
defers thegetattr
until we refer to
mypy.nodes.X
, which in this case is late enough for the import to have
finished
I suppose the reason this feels ugly is that circular imports are more
common in statically typed code than dynamically typed code (I guess) so
the original python import system design didn't have much pressure to make
circular imports particularly nice.
What if we rewrite from p import m
where m is a module to import p.m
,
then rewrite references to m
later to p.m
?
On 28 January 2013 09:44, Jukka Lehtosalo [email protected] wrote:
Circular imports have been a problem earlier as well. Much of the code was
ported from Alore, and Alore places few restrictions on circular imports.Why can't we use things like from mypy import nodes to keep the old look
of the code?Here are a few more potential ways of dealing with circular imports:
If they only affect type signatures and casts, we can allow them and
erase the related imports automatically, since type signatures are erased.
For overloads, where we can't just erase them, we can generate fully
qualified names. This feelts hacky, though, and can break clients that
expect the imported name to be there.Automatically move circular imports to the bottom of the file, and
rename references within the file to use fully qualified names. I'm not
sure how reliably the transformation can be done, though.Refactor the code to not have circular imports. This probably
involves at least moving more code to the nodes module. Also type checking
and transform related modules may have to be combined (though I guess this
is less problematic there, and it's easier to live with the fully qualified
names).—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-12774501.
from mypy.
Ah, now I see.
It seems that import a.b
looks up 'a.b'
directly from the sys.modules dict, but from a import b
looks up module a
, and then the attribute b
of a
(as you said). So another alternative might be to do something like this instead of from a import b
:
import a.b
import sys as __sys
b = __sys.modules['a.b']
Quick testing indicates that this works. However, it adds a
to the module name space. So to be safe, we may need to do something even more ugly:
__a = a # only if a is defined in the module
import a.b
a = __a # or del a, if a is not defined in the module
import sys as __sys
b = __sys.modules['a.b']
(The above has not been tested, though.)
Not sure which of the transformations is the better approach. In any case, we should probably only do the transformations if there actually are cyclic imports.
from mypy.
Here are some ideas.
Statically typed code tends to make heavier use of circular imports, but they primarily affect type declarations. However, I think that in this case it's better to refactor the code to use (fewer) circular imports. But this should be done as a separate task after the refactorings have been merged into master. Later on, we may decide to add better support for circular imports in the Python back end as another separate task.
So I suggest we proceed like this:
- Use fully qualified names and implement the refactoring so that it works with the current implementation.
Don't worry if the code is a bit ugly. - Do some testing in the branch.
- Merge the changes to master. Make sure that everything works after the merge.
- Combine the modules which are the worst affected by the circular imports as a separate task (I'll open an issue).
Clean up the code.
from mypy.
When you refer to refactoring in the first step, do you mean refactoring
into packages? (As opposed to refactoring the circular imports)
On 1 February 2013 12:34, Jukka Lehtosalo [email protected] wrote:
Here are some ideas.
Statically typed code tends to make heavier use of circular imports, but
they primarily affect type declarations. However, I think that in this case
it's better to refactor the code to use (fewer) circular imports. But this
should be done as a separate task after the refactorings have been merged
into master. Later on, we may decide to add better support for circular
imports in the Python back end as another separate task.So I suggest we proceed like this:
Use fully qualified names and implement the refactoring so that it
works with the current implementation. Don't worry if the code is a bit
ugly.Do some testing in the branch.
Merge the changes to master. Make sure that everything works after
the merge.Combine the modules which are the worst affected by the circular
imports as a separate task (I'll open an issue). Clean up the code.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-12992241.
from mypy.
Yes, I mean only the original refactoring into packages.
from mypy.
The other refactoring (removing circular imports) is now issue #93.
from mypy.
I'm going to rename mtypes to types. Then we can close the issue.
from mypy.
Related Issues (20)
- new generics should be inferred as covariant instead of invariant on frozen dataclasses
- `functools.reduce` over sets: empty set not accepted without annotation
- `functools.reduce` over sets becomes unacceptable when used in a larger expression
- Assertion Error in StubtestUnit::test_protocol with Python 3.7 Environment HOT 2
- assignment to `_` inside a function incorrectly becomes `Any`
- constrained TypeVar and star operator incompatible type
- `--untyped-calls-exclude` does not exclude some packages/libraries HOT 1
- Mypy cannot guess callable return type (`Tuple[Type[T], ...] -> T`) HOT 2
- Should mypy check existence of module attributes for unannotated modules? HOT 1
- False positive: "overloaded signature will never be matched" with Self
- module name assumed is __main__ for .pyw files on windows
- False positive when using `Self` as the return type with multiple base classes HOT 1
- torch-nn-functional-mypy-bug-when-torchvision-installed
- dmypy crashes from RecursionError for some complex expressions (fastparse) HOT 1
- PEP 695 variance inferred as simultaneously covariant and contravariant HOT 2
- False negative for invalid abstractmethod implementation
- False negative when accessing dataclass instance attribute as class attribute HOT 2
- Basic checking of format string compatibility in f-strings HOT 2
- Mypy errors on code that's trivial syntactic transformation of code that it does not error on
- AssertionError: Must not defer during final iteration
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mypy.