[IPython-dev] IPython with Color on windows
fperez at colorado.edu
Sat May 24 18:05:43 EDT 2003
Gary Bishop wrote:
> I *should* be working on something else but having fun with this. I'm
> going to have to quit (for a while at least) pretty soon.
No prob. Things under windows have never moved much, so all we get from you
is definitely progress :)
> There is a stylistic issue in the change that I think you should
> answer, even if I hack the code. This change could happen at least 2
> ways that I can think of.
> 1) Add a module that contains a file-like object that everyone uses to
> write to the console. Pretty easy to implement and small changes to
> modules. Outside windows the file-like object is just sys.stdout.
> Inside windows it is some filter code that uses my console code.
> 2) Pass the object down into the various other classes (ultraTB,
> Inspect) using their init methods. Might be doable but I'd have to
> understand the code a lot better than I do now.
> Other possibilities? Preferences?
Well, I favor something like 2. It seems to make sense to instantiate the
main ipython shell object with a pair of optional stdout/stderr arguments. If
not given, they default to sys.stdout/err as usual. If given, these are used
by the controlling class to pass down to other objects it uses which offer the
same protocol. Currently most write directly to stdout/err, but this would be
easy (though time-consuming) to change.
Something like 1 would only work if we write a file-like object and set
sys.stdout to it. The moment user code resets sys.stdout, we're toast. I've
already seen failure cases like this at initialization time, were I have
file-like objects for trapping output. It's a disaster, and I'm actually gong
to remove all that code. I'll leave the OutputTrap modules in the
distribution in case someone uses them, but I'll stop using them inside ipython.
So we need to have _our_ functions write to their special channels, without
messing with what the users expect to be normal sys.std* behavior. ipython
should mimic, as much as possible, a plain vanilla python interpreter as far
as how user code behaves under it.
As I said, this can be quite time-consuming. If you plan on diving head first
into it, opening a separate cvs branch may be a good idea so that this effort
can progress at its own pace, without halting regular bugfixing/small
improvements. This is good, but a somewhat 'big architecture' kind of job.
More information about the IPython-dev