In the last 15 years, I haven't encountered many coders or organizations that produce code that think machine code or bytecode is significantly "secret".

The sentiment I mostly encounter is:

Secrets are things that are encrypted.

Compiling (to bytecode or machine code) is just a way to let different kinds of "machines" read the code.

(Paranoia seems to amplify that attitude)

Naively compiled C/C++ is fairly easy to reverse engineer (I say this from a lot of experience!).

If you want to "protect your source code" you need to apply obfuscation techniques to slow down a reverse engineer - but keep in mind that everything ultimately can be reversed and understood given enough time. Plus, many obfuscation techniques can be made applicable to Python code too (e.g. encrypting, obfuscating or mangling Python bytecodes).

The real question is: what are you protecting that is so secret? If it's details about a protocol (network messages, file format or external API calls) those are fairly easy to dissect externally. If it's a proprietary algorithm, someone could blackbox the relevant parts of your code to use in their own application, without even reversing it. If it's proprietary data, client-held keys, etc. there are ways to get at it. Assume that everything you hand a client is no longer secure or private - if you really need to keep secret sauce close to home, make it server-side.

> Naively compiled C/C++ is fairly easy to reverse engineer (I say this from a lot of experience!).

So I assume your position on reverse engineering Python bytecode is that it's trivial.

It can be, since Python is a higher-level language, but it isn't necessarily easier. For one, the state of decompilation technology is much more primitive for Python - the decompilers I've used are more like pattern matchers and break if you even slightly tweak the bytecode or use fancy constructs.

Second, although Python by default outputs plenty of symbolic data to assist a reverse engineer, these can be stripped (just like a C/C++ binary can be stripped), leaving you with a bunch of duck-typed method calls and operations.

> One of the biggest Python issues I see is the inability to hide or protect Python source code.

As with other code (source or object), it is protected by means of law.

If you want to hide it, run a service on a computer you control and sell access to the service.

There's probably not that much code that is so unique and difficult that it could not be reimplemented quickly from a spec. On the other hand, if the code happens to be part of a large system, it gets increasingly difficult to understand and use, from just a code dump without author support.

I submit that those two sets don't intersect much, and probably why this issue does not get much attention. Cython might be a solution.

There's decompilers and deassemblers.

Code is not hidden or protected by being transformed into a binary executable format. Companies that believe/rely on that are disillusioned, not paranoid.

>>I would be curious to know how other folks hide/protect Python code?

With lawyers.

Most of the commercial products that are written in python come in with a EULA that says "don't touch".