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

[Fernando Perez]

On Sun, Mar 15, 2009 at 2:27 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Mar 15, 2009 at 10:57:52AM +0200, Ville M. Vainio wrote:
>> On Sun, Mar 15, 2009 at 2:27 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> > The two key things we need to do, probably right after the 0.10 release:
>
>> > 1. Stop putting Extensions into sys.path.  This is just bad practice,
>> > as it pollutes people's import path with our stuff.  Users who want an
>
>> -1. This just breaks stuff without any real benefits (provided that
>> there are no collisions - something taken care of by ipy_ prefix).
>
> Monkey patching sys.path is ugly and fragile. it makes code impossible to
> run without going throught the one given entry point, and most often
> break Python import priority. I am +1 on the proposition.

Yup.  Unfortunately the mistake we made was to allow the decision in
the first place, because yes, now this will be an API breakage we'll
have to announce loudly.  But the whole ipy_* naming convention is
ugly (and there are a bunch of things in there with non-ipy_ names
already), and my point is precisely Gael's: applications should
*never* mess with sys.path under the user.  Setuptools does that:
arguably they can't avoid it to support namespace packages, but it
still causes no end of grief under certain circumstances.

In our case, the only justification is to save users a few characters
when loading ipython extensions so they can do it implicitly.  That's
breaking the 'explicit is better than implicit' mantra for no
justifiable reason.

I realize you (Ville) like this, but I'm afraid it was a mistake that
we must correct now rather than later.  There's a good chance this
summer we may get some funding to support Brian doing some serious
refactoring of the core, and now is the time to get all our APIs in
order.

Honestly, I allowed some of these changes that I felt were ill-advised
when I thought that the ipython1 work would simply replace ip0, and
that we would get all new APIs.  I simply didn't pay close enough
attention to what was going into ip0, thinking it would be an
end-of-the road code, which turned out not to be true.  It was my
mistake, 100%, I admit that.  But I'd rather face up to my mistake
now, fix things and endure a minor API breakage, than live with these
problematic decisions for the long haul now that we are all using that
codebase for the core and that all the code developed in ip1 is
building on top of it as its foundation.

BTW, I'm not proposing this to change for 0.10, no. It's for the next
release, and we may actually put in a deprecation warning

Cheers,

f