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
