Here are my next 50 commit reviews:

1274, 1275
==========

1276
====

Brian needs to look at this. Create a ticket for this.

1277, 1278
==========

1279
====

I really don't like that we have to do this stuff to run out test suite. 

Putting get_ipython in __builtin__ is a bad idea as it suggest that
get_ipython is a global function which is can't be (it always needs to be
attached to a particular InteractiveShell). I worry that with our test suite
having this global, people will start to write their code expecting this (see
above comments on how the pretty extension calls the global get_ipython).

Also, this code is where we are creating an IPythonApp, but we should
probably be creating a raw InteractiveShell.

....the code smell of this is still bad...

1280
====

1281
====

Oooohh, I love this!

1282
====

1283
====

I see you are deleting all the NoConfigDefault keywords arguments.  It is 
important that the default is set to this. The config system won't work
otherwise.  How is this being handled?  If it is not handled properly, 
the command line options won't be able to override those of the command line.

Also, the parallel computing apps also rely on this particular handling of
NoConfigDefault.  Those need to be updated if there is a new way of this
working.

1284
====

The defaults are not set to NoConfigDefaults, so it is not clear the config
system is working properly.

In ipclusterapp.py it looks like this is handled by the argument_default
argument to ArgumentParser.

In ipclusterapp.py 364,365, these should capture the deferreds (d, d2) even
though we are not using them. This is to emphasize that these functions
return deferreds.  This code is super subtle to debug and it helps to
show which functions return deferreds.  Either that or make a comment about
these functions returning a deferred.

Same issues about NoConfigDefault in ipcontrollerapp/ipengineapp.

1285, 1286, 1287, 1288, 1289 
============================

1290
====

Let put new utilities (like teee) in their own modules rather than genutils.
This will at least prevent the genutils situation from getting worse. Also,
new things tend to get lost in genutils.

1291, 1292
==========

1293
====

application.py:

The logic in Application is already extremely complex. I think that adding the
new constructor_config and override_config logic takes the complexity over the
top.

The main goals of an Application are to manage the complex logic of building
a config from the command line and config files. The new constructor_config
and override_config logic seems like it is simply trying to get around
what Application is doing. This basically makes Application *more* complex
in order to get it doing less.

I think this is a perfect case where we should simply directly instantiate
an InteractiveShell class directly.  All options can be passed by creating
a single config object and setting its attributes as needed.

This approach will limit the complexity in Application and provide a simpler
way of simply instantiating the object you want.

I think it may be just the old habit of thinking of Application as the
refactored make_ipython function. In reality, the parts of the old
make_ipython you want to use are now in the __init__ method of InteractiveShell

Let's talk about this more though.

Same is true of Application.initialize.

1294
====

Very nice stuff!

globalipapp.py:  Again, I think start_ipython should just instantiate
an InteractiveShell directly, rather than creating an IPythonApp.

1295, 1296, 1297
================

1298
====

Same comments as above about globalipapp.py

1299, 1300
==========

1301
====

I am a little unsure if w should allow %HOME% to be set on Windows. Do you 
know of a real usage case for this. Can we move it to a last ditch attempt?
Because this is before %HOMESHARE%, some network users could be messed up
by this. I guess I would rather stick to the win32 standards on this one.

1302-1312
=========

1313
====

Ahh, this explains why the parallel computing stuff has not been able
to use color!

We need to go through all of IPython and decide when Term needs to be used
and when we can just "print".  Currently, it is almost random when Term is
used.  This should be done as we look at supporting the new print function of 
2.6/3.x

Let's create a new ticket to remind us to do an audit of how Term/pritn are
used in our code base.

1315
====

Let's move outdated testing code to the attic (mkdoctests).

1318
====

Will this cause nose to try to run unittests in kernel/tests?  If so, we can't
do this.  When we previously had nose running these tests, we had serious
problems (failing tests not showing up, etc.).  I would prefer to keep nose
and trial completely orthogonal.  Yes, I know this means not having docttests
in twisted using code.  But I think in that case we can use our new decorator
approach that create a unittest (trial should find that).