[IPython-dev] InterpreterPasteInput.py => ipy_interpreter_paste.py

[Fernando Perez]

On 8/7/07, Ville M. Vainio <vivainio at gmail.com> wrote:

I'm cc-ing the dev list so this discussion is available to other
developers with commit rights.

> Hi,
>
> could you change the file name as suggested in the subject? It's very
> handy to see what ipy extensions/profiles are availably be entering
> "import ipy_<TAB>".

No, it will break backwards compatibility unnecessarily.  People have
existing installations with profiles that may call this file with the
old name, and there's absolutely no point in having an ipython update
break their installs.

We strive to keep things compatible with existing behavior.  Adding
features is great, but I see a lot of gratuitous changes here and
there, things that after an svn update stop working, etc.  I haven't
said anything because I don't want to appear to get in the way of
developing, but I think perhaps I should.

Once we have a project out that many people use daily, we should
really triple-think the justification behind changes that can break
daily usage patterns.  Even if a change is somehow an improvement
(though I fail to see how %hist changing to returning raw history is
one, it just bit me a few days ago), that has to be weighed against
existing user practice.

In cases where a change is a feature addition, we should just go for
it.  But wherever we break how a command used to work or any other
backwards-incompatible change, we should have a *really* good
justification for it.

I've started a separate file in doc/ besides the changelog, called
api_changes, where we should list any backward incompatibilities.
This can be as simple as copying over a changelog entry, but it will
help users be aware of what to look for in terms of potential
problems.

*****
For all developers: PLEASE document in api_changes any
backwards-incompatible change you make.  And do so AFTER we've
discussed here that such breakage is really necessary.

Matplotlib has had such a development policy for a long time, we
should have as well.  Now we do.
*****

I'm not saying we *never* break compatibility, but that we should only
do so if absolutely necessary.

Your original question is better answered by having an
ipy_interpreter_paste module that wraps the necessary functions in the
other one.  Note also that ipy_interperter must NOT actually import
the other one, since that one (unfortunately) installs its prefilter
unconditionally on import.  So the best alternative is probably to put
the implementation in ipy_interpreter_paste, and leave the old one
(for backwards compatibility) to load and activate it from
ipy_interpreter_paste.

That solution gives us:

- your desired tab completion
- backwards compatibility
- a cleaner behavior of the new module, which instead of
unconditionally installing the filter, will have something like an
activate_input_filter() routine that does the activation.

The old module could then become

from ipy_interpreter_paste import *
activate_input_filter()

and its code would be moved into the new ipy_interpreter_paste.

> Also, there is the general rule that advices against upper / mixed
> case module names...

Yes, the old codebase is a naming mess.  Again, not something worth
breaking every user's installation for.

The IPython1 codebase is much stricter on its naming/coding standards,
enforcement of documentation, real testing, etc.

Cheers,

f