Vaideeswaran Ganesan writes:
Intent is to make a web interaction as if you're working with local function. This is very well known design pattern called Proxy.
Sure, but the stdlib is fairly low-level. The question is not whether this module is useful. I'm sure for some purposes it is very useful. The question is is it useful for enough common Python tasks, or is it so likely to be frequently implemented incorrectly, that we should provide *and maintain indefinitely* this module. This is a big problem for this particular module. "Maintenance" often is more than bug-fixing, it includes developing new features. I'm pretty sure that this module would attract a very large number of requests for enhancement, often contradictory (eg, "implicit fetches should use GET, vs. implicit fetches should use POST"). I don't think that's a good use of core resources as the proposal has been presented so far.
It also simplifies the programmer allowing same experience whether you are working with local or remote interfaces.
Yes. Please don't assume people who are unfavorable to your proposal are unaware of its theoretical advantages. Show us parallel code examples with at least very close semantics. If you won't/can't do that much, many of us will make very unfavorable assumptions about your willingness/ability to maintain the module (and somebody needs to promise to do that, with you the obvious candidate).
Given the examples I have seen (swagger, sushi), we should see where this could be relevant.
That logic is invalid for Python. What we *should* do is make sure that Python works as documented (the fundamental contract of any software) and provides the *necessary* tools to get work done (the Python-specific "batteries included" policy). We provide the hammer and saw, which are not so easy to make in your home workshop. You use those tools to build a workbench. As useful as a workbench is, Python doesn't need to provide it once it does provide the hammer and saw. Obviously, this is a matter of judgment. Is pyopenapi more like a hammer or a workbench? At first glance, I say it's like a workbench. It's your job to convince this list (you don't need to convince me personally), and eventually enough core committers, that it's enough like a hammer to be included. As for swagger and sushi, I haven't seen them, and I don't intend to look at them because I have more than enough frameworks that I'm already using that I'm dangerously underinformed about. Where I have time, I study them, I don't look for more trouble elsewhere. So presenting information about examples is *your job as proponent*. The *default* is to continue the status quo (you can freely contribute the module on PyPI, which is not at all a bad deal). *You* need to show that this module benefits *Python* if included; Python needs no reason at all to say "put it on PyPI, please, so if I ever want it I can find it easily". Steve