Comments (9)
pallets/click#1880 (comment) seems applicable here:
This is noisy, I don't plan to make this change. You can add the following config to your project to allow Click (or other packages) to do this, it's a very common pattern. I suggest you have further discussion with mypy about the strictness of this, it sounds like they're open to it or may already have an open issue about it.
[mypy-click] no_implicit_reexport = False
(substitute "bidict" in place of "click")
See also pallets/click#1879 (comment) (by one of the mypy developers):
That said this seems a bit too strict in this case, so maybe mypy should change its behavior to be more permissive here.
from bidict.
While I agree that __all__
is not an ideal solution, is a working solution we have available today. Feels sub-optimal to leave this issue unresolved, and hope for some magical better solution for which there's no plan at all. It's not ideal but is the best we have, so until we come up with a better solution IMHO we should use it.
from bidict.
Hi @FlorianKoegler, thanks for opening this.
I deliberately removed __all__
, deliberately do not configure mypy with --no-implicit-reexport
, and want to keep it that way. From a maintainer's perspective, __all__
is error-prone and annoying to maintain, because it requires duplicating the names you mean to export in two different places. In return, it primarily just allows you to customize how wildcard imports work, which are bad practice in the first place. I prefer to not customize Python's default wildcard import behavior, where e.g. from bidict import *
only imports the names in bidict.__init__
that don't begin with underscore. For anything that I import into bidict.__init__
that does not begin with underscore and that I don't want to export, I use as
to give it a leading underscore, e.g.
Line 53 in 2f0a387
I think mypy's --no-implicit-reexport
is turned off by default for good reason. For many projects, including projects like bidict that are already being careful about what's exported from where, it's not a desired setting.
Hope this helps clarify!
from bidict.
I prefer to not customize Python's default wildcard import behavior, where, e.g.
from bidict import *
Note here, though, that the __all__
is not only used for star import. I'd say that's probably one of the least interesting features provided by it. It makes it explicit what's to be exported from a module. Without this, if you have a module that uses typing.List
that type is also exposed in that module namespace. For example:
from typing import List
def generate_list() -> List[int]:
return [1]
This module will provides both generate_list
and List
as available to import. I think we can agree that List
should not be imported from this module, but rather keep importing it from typing
. Without the __all__
expressing this, the linters/IDEs have no way to know this.
from bidict.
While I agree that the behavior without using __all__
has this problem, I don’t agree that __all__
is a good solution to the problem, for the reasons I gave above (manually maintaining the list of exports in a separate place from where they’re defined is tedious and error-prone). I’d rather wait for a better solution than use this bad solution.
from bidict.
What would be a better solution in your eyes, would you propose any?
from bidict.
I am hoping someone more qualified - who’s studied, or even designed, module systems for several languages - will propose something.
I know that there are other dynamic and gradually-typed languages whose designs avoided this problem from the start, but designing from scratch is a very different problem from improving an existing design.
In any case, if you’re interested in discussing Python module design questions further, I encourage you to do so on the Python-Dev list or some other place with a wider and more appropriate audience than this closed issue.
from bidict.
If everyone always just accepted the one bad solution available, there would not be any pressure to create better solutions.
Please try not to presume one size fits all especially when there are tradeoffs involved and especially for open source projects where the work is done voluntarily. Open source maintainers have the right to evaluate the tradeoffs associated with any particular new suggestion and make the right decision for their projects based on their circumstances.
from bidict.
I gave up and did the “import foo as foo” dance in the latest release, out now: https://bidict.readthedocs.io/en/v0.22.0/changelog.html
Hope this helps!
from bidict.
Related Issues (20)
- global name 'BidirectionalMapping' is not defined HOT 21
- github git tags out of sync since 0.18.4 HOT 3
- logo HOT 5
- Dependency Dashboard
- Type hints for Bidict type HOT 2
- Try slipcover HOT 1
- Maybe use nix for devcontainer and GHA “tests” workflow
- Why it returns None when I use bidict?
- Will you add a persistence method? HOT 1
- Improve OpenSSF Scorecard HOT 6
- Swap syntax does not work HOT 4
- Automate upgrading dev dependencies HOT 1
- Type alias definition for `MISSING` results in type violations HOT 1
- test fails with python3.12 HOT 3
- Remove dead batteries
- 0.22.1: temp directory in source tree trashes build HOT 6
- 0.22.1: sphinx warnings `reference target not found` HOT 6
- mypy type inference change in 0.23.0 HOT 12
- Recommended performant alt for `namedbidict` HOT 2
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 bidict.