Hi,<br><br>I am making progress on re-organizing all the top-level modules of IPython into logical sub-packages.  You can monitor my progress here:<br><br><a href="https://code.launchpad.net/~ipython-dev/ipython/module-reorg">https://code.launchpad.net/~ipython-dev/ipython/module-reorg</a><br>
<br>Overall, I am extremely pleased in how this is going - I think it will make a huge difference in making IPython easier to understand and develop.  But, before this branch is merged into trunk, we need to decide how to handle certain aspects of backwards compatibility.<br>
<br>Certain things in Ipython have become a sort of informal developer API (like ipapi) by others.  For the most commonly used developer APIs we need to put in &quot;shims&quot; as Fernando would calls them.  These shims will:<br>
<br>* Temporarily allow people to import the dev API things the old way.<br>* Print out a warning that the old way is depricated and will go away.<br><br>The quesiton is this:  what modules and classes do people think need to be handled in this way.  I want to keep the number as small as possible (I am NOT going to shim the whole project!), but I also don&#39;t want to leave out really important things.  In my mind, the goal here is NOT backwards compatiblity, the goal is to ease the transition to new APIs and package organization.<br>
<br>I really need to feedback from people like Fernando and Ville on this as they have the best idea of what things fall into this category.<br><br>Cheers,<br><br>Brian<br><br><br><br>