rust: improve plugin system for file IO #243
Conversation
Introduces a companion library: pylib. This could be a submodule. Gets us closer to with_open.py example in CI Introduces a few new concepts: MODULE_DISPATCH_TABLE - this is where you map module names (tempfile.xxx) DECORATOR_DISPATCH_TABLE - tells the transpiler what the decorator is doing FUNCTION_DISPATCH_TABLE - looked up on attributes as well as func dispatch
| for c in mode: | ||
| if c == "w": | ||
| if not is_binary: | ||
| self._usings.add("pylib::FileWriteString") |
There was a problem hiding this comment.
while crate name pylib is available, I don't think that accurately describes the purpose. py2many-helpers is as good a name as I can think of, and is a name which could be used for similar libraries in other languages.
There was a problem hiding this comment.
Also a name like this implies that nobody should rely on its API, which I guess will fluctuate as the needs of py2many evolve, and I expect some parts of it might become separate crates when components become mature.
There was a problem hiding this comment.
Someone could use such things without using py2many right? nim's pylib existed before py2many.
There was a problem hiding this comment.
Re "This could be a submodule." I would rather we didnt go down that path. IMO (2 cents worth) it makes sense to have the helpers as part of this repo, or using cargo's git repo support for libraries not on crates.io, and then as it stablises it can be a published crate on crates.io. Obviously your call, and not a big deal either way.
There was a problem hiding this comment.
Re nim pylib, its stated goal seems broader than you are likely to want to entertain/maintain. c.f. Yardanico/nimpylib#11
And say for example that we put some strenum voodoo into rust pylib, because it is missing in strum, what would happen if strum adds that feature -- I would hope that the rust pylib removes that extra functionality as it is no longer needed. otherwise the rust pylib becomes a huge library full of things people depend on that py2many no longer needs. Just my 2c.
There was a problem hiding this comment.
Yes - submodules are a pain to maintain. Perhaps fetching from crates.io is a better option.
I would hope that the rust pylib removes that extra functionality as it is no longer needed.
What you're saying is that the bar should be higher for something to be added to pylib. Rust doesn't have an ABI guarantee yet. So what remains is marking things stable/unstable, so users have a hint about API stability.
Looking at nim pylib's list - things like hasattr/getattr/isinstance and anything that depends on runtime types is out for us. Some like pow are covered by AST transformers. Hopefully it's a much smaller list of frequently used python idioms.
Introduces a companion library: pylib. This could be a submodule.
Gets us closer to with_open.py example in CI
Introduces a few new concepts:
MODULE_DISPATCH_TABLE - this is where you map module names (tempfile.xxx)
DECORATOR_DISPATCH_TABLE - tells the transpiler what the decorator is doing
FUNCTION_DISPATCH_TABLE - looked up on attributes as well as func dispatch