[IPython-dev] IPython module and package reorganization

[Darren Dale]

On Thu, Jul 2, 2009 at 1:50 PM, Brian Granger <ellisonbg.net at gmail.com>wrote:

> If you got rid of 2.4 support we could do this, but we still support 2.4.
>

How much longer will you continue to support python-2.4? If dropping support
for python-2.4 provided you with the flexibility to reorganize ipython the
way you want, wouldn't that be a compelling reason to do so?

Darren


>
> On Wed, Jul 1, 2009 at 2:24 PM, Darren Dale <dsdale24 at gmail.com> wrote:
>
>>
>>
>> On Wed, Jul 1, 2009 at 3:46 PM, Fernando Perez <fperez.net at gmail.com>wrote:
>>
>>> On Tue, Jun 30, 2009 at 2:49 PM, Brian Granger<ellisonbg.net at gmail.com>
>>> wrote:
>>> > I would love to be able to type "ipython" rather than "IPython" all
>>> > the time so I am for this change.  What do others think?  Are there
>>> > problems with this that I am missing?
>>>
>>> I personally would *love* to do this now.  I remember pulling back
>>> from this change a long time ago when we realized the problem on
>>> OSX/Windows because of name clashes.
>>>
>>> One aspect of this change does worry me though: there's a LOT of code
>>> in the wild that embeds ipython in all manner of tools, and we'd be
>>> breaking all of that with this change.  While we're all on board with
>>> doing backwards-incompatible changes, it would be nice to keep *some*
>>> level of backwards compatibility, even if done with shim layers.  We
>>> could provide a few shims so embedding code like
>>>
>>> from IPython.Shell import IPShellEmbed
>>>
>>> continues to work for one or two more releases, with proper
>>> DeprecationWarnings raised.  But if we rename IPython -> ipython, I
>>> don't see a way to expose any backwards compatibility mechanism.  And
>>> I think all changes of this kind should strive for a fair balance
>>> between necessary evolution and limiting the damage for existing
>>> users: there's no absolute right answer here, just a matter of finding
>>> an acceptable compromise.
>>>
>>
>> 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/.
>>
>> Darren
>>
>
>


-- 
"In our description of nature, the purpose is not to disclose the real
essence of the phenomena but only to track down, so far as it is possible,
relations between the manifold aspects of our experience" - Niels Bohr

"It is a bad habit of physicists to take their most successful abstractions
to be real properties of our world." - N. David Mermin

"Once we have granted that any physical theory is essentially only a model
for the world of experience, we must renounce all hope of finding anything
like the correct theory ... simply because the totality of experience is
never accessible to us." - Hugh Everett III
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20090702/133fdcb1/attachment.html>