Listen Print Discuss

Why I Stopped Coding and Why I'd Start Again
Pages: 1, 2, 3, 4

This can be done in such a way that indicating a local or networked source becomes simple. An import path such as /widgets/helloworld indicates a local file path. A path such as http://helloworld.foocorp.com points to a network file store. There could be other syntax, of course, but this is one example of an easy way to do this.



Dynamically Loaded Binaries

Like many languages, Python allows you to talk to external binaries, typically written in C or C++, to talk to hardware APIs, or to optimize performance for especially CPU intensive tasks. The issue with these, of course, is that it is difficult and many times impossible to make this type of code portable because the API the C program talks to (a telecom interface, for example) does not exist on many platforms.

For this type of module, how about a slightly different syntax to tell the runtime environment to load an external binary? This also requires changes to the runtime environment, which I'll discuss later. In our hypothetical language, we'd write:

import http://1_0_9.fastfft.widgets.code.foocorp.com type=bin runonce=n as=fastfft

x = fastfft()
fft = x.transform(some_pcm_audio)

This short example adds two parameters to the import statement, type=bin and runonce=y/n. This tells the runtime engine to fetch and launch a compiled binary that will process data from the application, not unlike a DLL. The runonce parameter tells the runtime engine whether it can launch multiple instances of the binary or only one.

The runtime interpreter hides the messiness of this process from the Python application and does something like this:

  1. Try to fetch a copy of the binary for the target platform; throw an exception if a problem occurs (for example, file not found, CRC error, etc.).
  2. Launch an instance of the binary and tell it to talk to the runtime environment via interprocess communication (for example, a localhost TCP socket).
  3. Pass data to/from the Python app via the interprocess communication interface.

This is a simple and fairly clean way to make it easy for Python apps to use external binaries. This itself is not news. A voice-scripting language I used years ago did something similar to this, minus the dynamic load and binding trick. The goal here is to make it easy to talk to binaries, but do so in a way that does not require the user to run a build command prior to running the application.

Using the example above, I want to use a C program that does a fast Fourier transform on a segment of audio data. This is a computationally intensive task, so it'll be a lot faster in compiled C than in an interpreted language such as Python. In this framework, the runtime engine launches an instance of fastfft.exe in the background and tells fastfft.exe to talk to it at localhost:nnnn.

From my perspective, I am just talking to something that looks like any other object. When I invoke a method, the runtime engine sends a message to the external application via IPC, does its thing, and sends a response back, which gets returned to my application. Simple.

Again, the details of how this works behind the scenes are not so important. I use TCP via localhost as an example, mainly because any networked appliance will, by definition, be able to talk via a localhost socket. In a real-world version of this, C and C++ developers will have a wrapper library that provides a simple interface in and out of their programs. The key requirement here is to eliminate the need to preload external modules, without the need for a build operation prior to running the program. It's worth losing a little bit of performance to gain this flexibility.

Built-In Version Control

You may have noticed that this system has a built-in form of version control. Code repositories must explicitly create a separate path for every version of a module. Likewise, developers would be required, or at least strongly encouraged to explicitly refer to a unique version at runtime.

Bootstrapping to a Web OS

This is a simple extension of a proven language. At the very least, it will make building and sharing applications easier, though it has potential beyond that.

Imagine a minimal machine that has the basic guts you need in a computer. Storage, I/O, and a network. It has a lightweight, built-in interpreter and is designed to run only Python apps. In effect, it's a Python computer and operating system.

When you first take this computer home, it boots up with a picture of a snake and a command line. You type the name of a program you want to run. Any program. Maybe you want to run an MP3 player, so you type "PyMP3".

Your computer is brand new, and you don't have that program yet, so behind the scenes it tells itself to:

import http://pymp3.code.widgetcorp.com

It then runs this program, and because it probably contains import statements of its own, automatically works through the underlying packages it needs to run. This all happens in the background, and after a short while, the program runs, as if it had been on your machine all along.

While many companies could do this, Google is in a unique position to make a system like this a reality. With its data center infrastructure and world-class software engineers, it can easily fund a project to make the necessary modifications to the Python interpreter (as well as other languages if desired) and to operate a trusted code repository--the two key ingredients required to build this system.

With the right sponsorship, a system like this could lead to major changes in the way developers build and share software. It could do so at a surprisingly modest cost, because this system requires only straightforward modifications to existing and widely used programming tools. Just as hyperlinking was a straightforward enhancement to document markup languages that enabled the development of the World Wide Web, hyperlinked source code will bring similar benefits to software development.

Brian McConnell is an inventor, author, and serial telecom entrepreneur. He has founded three telecom startups since moving to California. The most recent, Open Communication Systems, designs cutting-edge telecom applications based on open standards telephony technology.

Return to the Python DevCenter.