Python as network protocol

Steven D'Aprano steve at
Tue Nov 10 16:56:56 CET 2009

On Tue, 10 Nov 2009 16:31:13 +0100, Daniel Fetchinson wrote about using 

>> This is a *really* bad idea.
> How do you know for sure? Maybe the OP wants to use this thing with 3
> known researchers working on a cluster that is not even visible to the
> outside world. In such a setup the model the OP suggested is a perfectly
> reasonable one. I say this because I often work in such an environment
> and security is never an issue for us. And I find it always amusing that
> whenever I outline our code to a non-scientist programmer they always
> run away in shock and never talk to us again 

You might be a great scientist, but perhaps you should pay attention to 
the experts on programming who tell you that this is opening a potential 
security hole in your system.

No, it's not a "perfectly reasonable" tactic. It's a risky tactic that 
only works because the environment you use it in is so limited and the 
users so trusted. Can you guarantee that will never change? If not, then 
you should rethink your tactic of using exec.

Besides, as a general rule, exec is around an order of magnitude slower 
than running code directly. If performance matters at all, you are better 
off to try to find an alternative to exec.

> Nevertheless our code works perfectly for our purposes.

Until the day that some manager decides that it would be great to make 
your code into a service available over the Internet, or until one of the 
other scientists decides that he really needs to access it from home, or 
somebody pastes the wrong text into the application and it blows up in 
your face... it's not just malice you need to be careful of, but also 

The history of computing is full of systems that were designed with no 
security because it wasn't needed, until it was needed, but it was too 
late by then.

There's no need, or at least very little need, to put locks on the 
internal doors of your house, because we're not in the habit of taking 
internal doors and turning them into outside doors. But code designed to 
run inside your secure, safe network has a tendency to be re-purposed to 
run in insecure, unsafe networks, usually by people who have forgotten, 
or never knew, that they were opening up their system to code injection 


More information about the Python-list mailing list