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