<br><br><div class="gmail_quote">On Wed, Jul 29, 2009 at 12:59 PM, Ville M. Vainio <span dir="ltr">&lt;<a href="mailto:vivainio@gmail.com">vivainio@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed, Jul 29, 2009 at 9:17 PM, Brian Granger&lt;<a href="http://ellisonbg.net" target="_blank">ellisonbg.net</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>&gt; wrote:<br>
<br>
</div><div class="im">&gt; methods?  It gets darned confusing.  This confusion shows up in silly things<br>
&gt; like methods of InteractiveShell using ipapi rather than just calling its<br>
&gt; own methods!  I think this is an abuse of OO design.  Objects themselves<br>
<br>
</div>Using a separate &quot;api&quot; object allows you to actually move stuff out of<br>
InteractiveShell if necessary. It also allows you to rename, or in<br>
other ways reorganize the underlying implementation, without &quot;locking<br>
anything down&quot;. A &quot;proxy&quot; api object is able to survive extensive<br>
refactoring.<br>
<div class="im"></div></blockquote><div class="im"><br>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)<br>
<br>One approach is informal:<br><br>anything beginning with &quot;_&quot; is not part of the public api, anything else is.  <br><br>But, the problem is that someone will forget to add a &quot;_&quot; to an attribute and all of a sudden people will start to use it even though it is really private.<br>
<br>This is where Java folks (rightfully!!!) get to laugh at us pythonistas.<br><br>Having a separate api object is a way of saying, &quot;this and only this constitutes my public api.&quot;<br><br>But, originally, I was thinking of attributes only.  I don&#39;t like the idea of every class in IPython having itself and then a separate api class.  That seems redundant. <br>
<br>
&gt; have public APIs.  You don&#39;t need the extra indirection of a public API that<br>
&gt; wraps that public API.  I think the original reason we came up with ipapi is<br>
&gt; that InteractiveShell didn&#39;t have a clean public api.  But, once that is<br>
&gt; fixed, I think ipapi should go away.<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In static circles, it&#39;s a well known design methodology to restrict<br>
the interface you can use as much as you possible can, by not giving<br>
yourself access to all the internals (or making &quot;passing the boundary&quot;<br>
explicit, through having to use _ip.IP).  </blockquote><div><br>If by &#39;static circles&#39;&#39; you mean statically typed (like Java, C++) you still just use one object, not a separate api object to accomplish this.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It&#39;s true that<br>
implementation of the same concept for Python has been less than<br>
stellar success (adapt(), zope interfaces, ...), but it still make the<br>
code more &quot;approachable&quot; than building a monolithic &quot;everything goes&quot;<br>
mess.<br>
<br>
Regarding ipapi going away - I don&#39;t think it technically &quot;needs to&quot;,<br>
apart from the parts that don&#39;t make sense for new ipython<br>
architecture. Regardless of how magic functions are implemented, it&#39;s<br>
reassuring to know you can always use expose_magic to create a magic<br>
function - it may not be the most flexible way, it may jump through<br>
various hooks, but the user can rest assured that you will eventually<br>
have that magic function available.<br>
<br>
It just doesn&#39;t make sense to break a public API for the matter of<br>
taste alone, in the spirit of &quot;I&#39;d rather have this here&quot;, if the<br>
semantics of the new API are portable with the semantics of the old<br>
one. Let&#39;s have the new clean API first, and consider breaking<br>
compatibility when it is necessary. (i.e. when the new arcticeture can<br>
no longer support functionality of the old one). </blockquote><div><br>That is my plan.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I&#39;m sure most of the<br>
&quot;legacy&quot; ipapi can easily be hacked to work with the new stuff by an<br>
afternoon of coding.<br>
<font color="#888888"></font></blockquote><div><br>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!<br>
<br>Cheers,<br><br>Brian <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
--<br>
Ville M. Vainio<br>
<a href="http://tinyurl.com/vainio" target="_blank">http://tinyurl.com/vainio</a><br>
</font></blockquote></div><br>