-
-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose most of trio._util and trio._deprecate for the benefit of the Trio ecosystem #1504
Comments
Also useful: extract and publicize the logic from Runner.spawn_impl() for "either get a coroutine from this async function+args or raise an error explaining why it's not in the form I wanted" and "turn this function/name into a string". They're very useful for duck-nurseries (I have a hack in tricycle.open_service_nursery() working around the absence of the error-reporting one), and I think would find other uses too (#1513 made me think of this). |
Heh, I was just wondering whether to comment on #1513 to suggest this before I saw your post :-). Maybe
These I'm not as sure about. They're all pretty simple one-off things; the kind of code where the implementation is shorter than the documentation? And I'm reluctant to clutter Trio's API with random Python utilities.
|
You're right that most of these are simple to copy or reimplement. The idea I'm driving at here is that we'll have a better and more polished-feeling ecosystem if all (or almost all) Trio libraries do these things the same way. They're not really about async I/O; the only reason to put them in Trio is because every Trio library already depends on Trio. I guess they do add to our public API surface area, but I feel like if we put them in a clearly delineated submodule of "helpers for writing Trio libraries that act like Trio in particular ways", they'll be easily ignorable by people who don't care about that. The only ones I feel strongly about are ConflictDetector, fixup_module_metadata, and deprecations. ConflictDetector can easily go in trio.lowlevel on its own. For the others, I guess a different package might be a better choice. The name |
Trio has great tools for dealing with some of the minutiae of making a polished Python package in general, but they're private; libraries that depend on Trio need to copy-paste or reimplement these tools if they want to offer equivalent functionality. If they reimplement, they probably won't do as good of a job.
I think we should add a new public Trio submodule (
trio.libtools
?) which provides:trio._util
: Final, NoPublicConstructor, generic_function, fixup_module_metadata, async_wraps, ConflictDetectortrio._deprecate
, substituting a project's own deprecation warning, issue URL, and name.The text was updated successfully, but these errors were encountered: