[IPython-dev] IPython with Color on windows

[Fernando Perez]

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.

Best,

f.