Skip to content

Instantly share code, notes, and snippets.

@traverseda
Last active June 22, 2019 18:22
Show Gist options
  • Save traverseda/2a55e696d8070575d1fb6eccd7b2c70c to your computer and use it in GitHub Desktop.
Save traverseda/2a55e696d8070575d1fb6eccd7b2c70c to your computer and use it in GitHub Desktop.

This is a proposal, no code has actually been written yet.

A python preprocessor that extends python syntax to make it easier to use python as a bash replacement.

Inspired by xonsh, we first determine if something should be running in "shell" mode or python mode.

print hello world #Shell mode
h0="hello world" #Python mode
print hello world | $h1 #Shell mode
assert h0 == h1 #Python mode
print $h0 #Shell mode
print(h1) #Python mode

Keyword arguments are automatically turned into regular arguments

print --file=$sys.stderr goodbye world

Classes are a bit more complicated, in these cases we treat the first keyword argument after a pipe as a method call on the returned object.

from pathlib import Path as path

path ./ | --iterdir

Keyword arguments that don't get provided a value are set to True

--somearg=True
--somearg

Are syntactically equivelent.


While all this piping peristant objects are great, they do have some drawbacks. The biggest is that any program you run would need to be loaded into your "shell" or interpretor. One of the big reasons why linux-style shells work is because each command (or "function call") runs in it's on process.

We can do the same thing using python remote objects (supplied by the rpyc library). When python shell launches a third-party application, it launches it in it's own python process, grabbing stdin and stdout to form a bidirectional communication protocol and supplying the user with a special wrapper object that forwards all it's calls to the sub-process. This python objects to run in their own virtual enviroment or even over ssh and still look like just a normal python object to the end user.

@traverseda
Copy link
Author

@scopatz, this is something I've been thinking about for a while, but I'm stuck on some implementation issues. Do you think you could explain exactly how xonsh is extending the python language? From a high level, like I know you're per-prosessing the text to convert it into something that python can evaluate, but how are you keeping line numbers consistent in tracebacks? There's a lot of details I don't understand, and a rough high-level overview could help me a lot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment