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

[Brian Granger]

On Wed, Jul 29, 2009 at 12:59 PM, Ville M. Vainio <vivainio at gmail.com>wrote:

> 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.
>

I was thinking about this over lunch.  One of the problems with not having a
separate runtime api is that it is difficult, when looking at a large class,
to know what constitutes its truly public api (at least for a language like
python)

One approach is informal:

anything beginning with "_" is not part of the public api, anything else
is.

But, the problem is that someone will forget to add a "_" to an attribute
and all of a sudden people will start to use it even though it is really
private.

This is where Java folks (rightfully!!!) get to laugh at us pythonistas.

Having a separate api object is a way of saying, "this and only this
constitutes my public api."

But, originally, I was thinking of attributes only.  I don't like the idea
of every class in IPython having itself and then a separate api class.  That
seems redundant.

> 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).


If by 'static circles'' you mean statically typed (like Java, C++) you still
just use one object, not a separate api object to accomplish this.


> 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).


That is my plan.


> I'm sure most of the
> "legacy" ipapi can easily be hacked to work with the new stuff by an
> afternoon of coding.
>

This is likely.  But my hope is that the replacements for ipapi will be so
far superior, no one will want to use ipapi anymore.  But until that amazing
new code exists, ipapi will live on!

Cheers,

Brian

>
> --
> Ville M. Vainio
> http://tinyurl.com/vainio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20090729/0f8c8035/attachment-0001.html>