<br><br><div class="gmail_quote">On Wed, Jul 1, 2009 at 3:46 PM, Fernando Perez <span dir="ltr"><<a href="http://fperez.net">fperez.net</a>@<a href="http://gmail.com">gmail.com</a>></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 Tue, Jun 30, 2009 at 2:49 PM, Brian Granger<<a href="http://ellisonbg.net" target="_blank">ellisonbg.net</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>> wrote:<br>
> I would love to be able to type "ipython" rather than "IPython" all<br>
> the time so I am for this change.  What do others think?  Are there<br>
> problems with this that I am missing?<br>
<br>
</div>I personally would *love* to do this now.  I remember pulling back<br>
from this change a long time ago when we realized the problem on<br>
OSX/Windows because of name clashes.<br>
<br>
One aspect of this change does worry me though: there's a LOT of code<br>
in the wild that embeds ipython in all manner of tools, and we'd be<br>
breaking all of that with this change.  While we're all on board with<br>
doing backwards-incompatible changes, it would be nice to keep *some*<br>
level of backwards compatibility, even if done with shim layers.  We<br>
could provide a few shims so embedding code like<br>
<br>
from IPython.Shell import IPShellEmbed<br>
<br>
continues to work for one or two more releases, with proper<br>
DeprecationWarnings raised.  But if we rename IPython -> ipython, I<br>
don't see a way to expose any backwards compatibility mechanism.  And<br>
I think all changes of this kind should strive for a fair balance<br>
between necessary evolution and limiting the damage for existing<br>
users: there's no absolute right answer here, just a matter of finding<br>
an acceptable compromise.<br>
</blockquote><div><br>Could the current IPython package be cleaned up to cooperate with relative package imports (using absolute_import from __future__)? Then packages that require the old organization could include it as a subpackage of their own projects, and the top-level ipython-1.0 can reorganize under ipython/.<br>
<br>Darren<br></div></div>