[IPython-dev] Extensions: decisions on loading them and API (thoughts from R. Kern's branch)

[Brian Granger]

>> As Fernando has eluded to, it looks like I may have some funding to
>> work on a refactor of the ipython core this summer.  I am very excited
>> to finally get a chance to wrestle the beast into submission.
>
> That's great news! Refactoring it does need some 8hour/day work, a
> privilege it certainly hasn't ever enjoyed...

Yep, it definitely will be a full time job for a while.

>> Another way of saying this is that the user's experience will be the
>> same or better, but a developer's experience will be *completely
>> different*.  This will unavoidably mean API breakage.  Where
>> appropriate deprecation warnings will be used, but in many cases, the
>> API will change so significantly that even deprecations warnings won't
>> be possible.  I will also try to do things in place and incrementally.
>
> It's a mixed blessing that the "public" api has been quite shallow.
> It's bad, because users have needed to go for InteractiveShell
> directly, but it's also good in that breaking the compatibility can be
> done without annoying too many ;-).

Yes, at some level, we don't have a ton of people who use the dev API.

> Most of the compatibility with IPApi can be retained quite easily,
> even with a radically different underlying implementation. Take
> expose_magic, for example, or custom completers.

Yes, where appropriate, I will try to maintain the API.  No reason to
change the parts that are not broken.

>> I will consult with the list extensively about design decisions and
>> hopefully as things move forward, others will be interested in helping
>> out.  After 0.10 is released, I will post to the list some more
>> details about my near future plans.
>
> Obvious targest that really need some care are completer.py,
> OutputTrap.py, genutils.py. Something to get started anyway ;-).

Plenty to get started with.  More details to come!

Brian


> --
> Ville M. Vainio
> http://tinyurl.com/vainio
>