Monday, October 31, 2005

Brian Ray's Blog : Python: IPython as primary Shell

Brian Ray's Blog : Python: IPython as primary Shell: "IPython , a Python interactive shell developed for the scientific computing community by Fernando Perez is such a powerful tool, I just may replace my default login settings from just bash [1] directly to IPython over bash.

How may people do this? I mean really! Is it practical to cross this line?

If you are new to IPython, there is a decent intro article from ONLamp. Although, I fail to see how this article fits into the LAMP [2] world. Still, it unveils some need features like: magic: Quickly assess special IPython features. Tab Completion: auto-complete code attributes, classnames, methods, and more Introspection: Easy access to Doc Strings and internal documentation History: store a dumpable session of commands Debugger Access: internal access to pdb Run: a safe way to run a file and ignore the __name__ == '__main__', trick Macros: capture command history into a macro

All great stuff. Also mentioned in the article is System Shell Access. For example, you can use cd, pwd, and ls directly in IPython. To escape to the shell use '!' or '!!'.

The IPython Manual notes in the section IPython as system shell. I loose job control if I use iPython this way. Although, I haven't had many issues so far.

Starting IPython with 'ipython -p pysh', creates a special envirom"

I found this interesting because of recent ideas I've been drawing up for a Python Embedded Shell. The Python syntax for `foo` being taken as repr(foo) is to be removed, so I thought, "Why not have a special interpretter to expand `foo` to execute a program named `foo`?"


I went into it more in my mind, so I'll lay out the ideas here.

  • foo=10 would be taken as normal
  • print $foo would be used to print it to the terminal
  • foo would just run the program, foo (I updated from the original thoughts)
  • $foo would run a program stored in the string foo by name
  • if, while, def, class, elif, else, and for all work as they currently do.
  • That $ syntax is only needed where it would be otherwise confused for a program name.
  • `foo` would resolve to a special object representing a new process running by executing foo. This process object would have stdin, stdout, and stderr file-like object attributes. It would also have kill, pause, and continue methods.
  • New operators exist for piping. Such as foo->bar to pipe stdout of foo to stdin of bar. foo!->bar pipes stderr, instead. null is known as a built-in process object, which just pipes everthing to /dev/null or an equivalent.
Very basic, not well polished. Besides, I think I like Monad, the Microsoft Shell, which is still in Beta, a lot better than my idea or any command line I've ever used. Sorry, my Linux buddies, but a good idea is a good idea, no matter who comes up with it.

2 comments:

Brian Ray said...

I was little suprised to see the M$ shell article link you posted. Syntax for data types looks like Python. I was not aware of this. Interesting.

Calvin Spealman said...

The syntax I showed was some ideas I had for a Python based command shell. But, between the time I thought of this and wrote the post, I got a chance to learn about Monad, which I might actually like better. I really like how commands aren't just programs to run that take a simple array of char pointers, but they actually take arguments in a standardized way, and all are forced to have some standard things you can expect (like only pretending to do things, or asking permission for each action), so you can trust things (or not) a little better.