[IPython-dev] App's, Components and refactoring

[Ville M. Vainio]

On Wed, Jul 29, 2009 at 9:17 PM, Brian Granger<ellisonbg.net at gmail.com> wrote:

> methods?  It gets darned confusing.  This confusion shows up in silly things
> like methods of InteractiveShell using ipapi rather than just calling its
> own methods!  I think this is an abuse of OO design.  Objects themselves

Using a separate "api" object allows you to actually move stuff out of
InteractiveShell if necessary. It also allows you to rename, or in
other ways reorganize the underlying implementation, without "locking
anything down". A "proxy" api object is able to survive extensive
refactoring.


> have public APIs.  You don't need the extra indirection of a public API that
> wraps that public API.  I think the original reason we came up with ipapi is
> that InteractiveShell didn't have a clean public api.  But, once that is
> fixed, I think ipapi should go away.

In static circles, it's a well known design methodology to restrict
the interface you can use as much as you possible can, by not giving
yourself access to all the internals (or making "passing the boundary"
explicit, through having to use _ip.IP).  It's true that
implementation of the same concept for Python has been less than
stellar success (adapt(), zope interfaces, ...), but it still make the
code more "approachable" than building a monolithic "everything goes"
mess.

Regarding ipapi going away - I don't think it technically "needs to",
apart from the parts that don't make sense for new ipython
architecture. Regardless of how magic functions are implemented, it's
reassuring to know you can always use expose_magic to create a magic
function - it may not be the most flexible way, it may jump through
various hooks, but the user can rest assured that you will eventually
have that magic function available.

It just doesn't make sense to break a public API for the matter of
taste alone, in the spirit of "I'd rather have this here", if the
semantics of the new API are portable with the semantics of the old
one. Let's have the new clean API first, and consider breaking
compatibility when it is necessary. (i.e. when the new arcticeture can
no longer support functionality of the old one). I'm sure most of the
"legacy" ipapi can easily be hacked to work with the new stuff by an
afternoon of coding.

-- 
Ville M. Vainio
http://tinyurl.com/vainio