[IPython-dev] IPython module and package reorganization
Thu Jul 2 13:42:54 CDT 2009
> 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?
I am not sure. I don't know how many 2.4 users we have. It would be very
nice to be able tyo use the 2.5 features like with and relative imports.
But I am not sure those features are sufficient to drop 2.4 support...yet.
What do others think?
>> On Wed, Jul 1, 2009 at 2:24 PM, Darren Dale <firstname.lastname@example.org> wrote:
>>> On Wed, Jul 1, 2009 at 3:46 PM, Fernando Perez <email@example.com>wrote:
>>>> On Tue, Jun 30, 2009 at 2:49 PM, Brian Granger<firstname.lastname@example.org>
>>>> > 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
> "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...
More information about the IPython-dev