>>For me accessing Python (CPython, which cery likely will be encountered in examples, as well as IronPython/Dotnet) from vfp via COM was a breeze - VB6 might have been minimally easier as "the" COM language, but VB has other warts ;-)
>
>I'm sure it's possible but requires that you have a working setup of those environments. .NET is pretty much baked into Windows or at the very least a single well defined upgrade away. Python on a Windows is not exactly a smooth setup path especially if you've never done it. Most people that do python tend to stay away from using it on Windows due to perf and config issues last I checked.
>

Python including Windows stuff (mostly COM and some API) was available also as portable packages, which in my book is ahead of most installer dependent stuff, esp. if registry needs to be involved. True, if you want to use many libs there can be trouble as they might expect different versions, but for wrapping you only need one of the versions described as working. And no problem with parallell installations as well reminds me of a defunct MS DB product ;-)

>It's always amazing to me how much effort can be wasted on implementing client proxies to call services. Over my years of working with SOAP I can't count how many times I've run into issues with services where the hosted service did some flagrant violation of common sense operations in WSDL that made it extremely difficult to get a stock proxy solution to work. Usually related around a) namespaces or b) security and nonces (which are insanely time consuming to solve).
>
>Plain HTTP ('REST') services are so much easier to deal with to avoid the data formatting issues that XSD and WSDL contracts have wrought. Yet SOAP seems to make no effort to be dying off. :-(
>

Would be interested to read about your opinion on GraphQL, which some think is the next step leaving REST behind.