On Tue, May 17, 2016 at 7:54 PM, Paul Rudin <paul.nos...@rudin.co.uk> wrote: >> Also: >> >> With a third party solution I don't need to fix the bugs. >> >> But with an in-house solution I at least *can* fix the bugs. >> >> The feeling of powerlessness can be crushing when you depend on a >> third-party component that is broken with no fix in sight. >> >> > > Presumably it depends on whether you have the source for the third party > component...
Yes and no. A student of mine asked me how hard it would be to use in Python a service that provided Java, .NET, and a couple of other SDKs, but not Python. Source is available for them, sure, but they're so massive and complicated that it's utterly impractical. (I had been hoping the SDKs were basically just offering a friendly API to an underlying HTTP-based service, but no.) So the options were (1) use Jython so the Java SDK became usable, or (2) fire off a subprocess that does the work and pipes it back to your app, or (3) spend about fifty years porting a gigantic lot of code to a new language. And if there'd been bugs in any of the code, well, options 1 and 2 mean my student (who knows Python but none of the SDK languages on offer) would be completely unable to fix it, source or no source - and with option 3, it'd make the port virtually impossible. Having the source available is great. It tells you which projects you DON'T want to touch. ChrisA fully aware that some of his projects will be in other people's "DON'T want to touch" boxes -- https://mail.python.org/mailman/listinfo/python-list
