Thanks Steve, This is very useful and actionable feedback. I'll work on the parallel examples. I'm pretty much sure, it might take few rounds of consultation to bring out the value.
I will also seriously think through the PyPI as an approach, as I seem to feel that OpenAPI is not really "all that universal". Regards, Vaidees. On Sun, Aug 8, 2021 at 8:34 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > 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 >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/K6JLX74JIBP7T45Z34EZIVRKWDLT3TKZ/ Code of Conduct: http://python.org/psf/codeofconduct/
