On Wed, Feb 12, 2014 at 1:24 AM, Roy Smith <r...@panix.com> wrote: > Whether I mind shipping my source, or you mind shipping your source > isn't really what matters here. What matters is that there *are* > people/companies who don't want to expose their source. Perhaps for > reasons we don't agree with. For those people, Python is not a good > choice.
But if it comes to that, there's really nothing that's all that great a choice. After all, a small amount of introspection will identify the external references in something (even C code has that, unless every single call is statically linked; and even then, I've used gdb usefully on other people's optimized binaries), so while someone might not be able to figure out how your code works, they can at least figure out what it's doing, and call on it directly. The only difference between a .pyc file and a binary executable is that the pyc bytecode is written for a virtual machine rather than a physical CPU. It's not a matter of "this is good, that is bad", but a spectrum of difficulties - optimized C code with everything statically linked is about as close to one extreme as you'll get without consciously obfuscating your code, and well-commented source is the opposite extreme. A minified source file, a .pyc file, or a dynamically linked .so, all are just someplace along that range. It's just a question of how much time and effort it takes to figure out the internals of the code. Considering that there are big companies spending lots of money devising DRM schemes, and their code often gets decompiled or reverse engineered within a day of release, I'd have to say that even obfuscated code is no real barrier. The *only* way to expose nothing is to publish nothing - which, these days, usually means running your software on a server and distributing a fairly dumb client... a model that MUDs have been using to great effect for decades, and are even today able to be run commercially. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
