[IPython-dev] InterpreterPasteInput.py => ipy_interpreter_paste.py
Tue Aug 7 13:41:00 CDT 2007
On 8/7/07, Ville M. Vainio <firstname.lastname@example.org> wrote:
> On 8/7/07, Fernando Perez <email@example.com> wrote:
> > 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.
> Why do you think "raw" mode for %hist is not an improvement? There was
> a bug a while ago that screwed up the numbering, but it's fixed now.
> Overall, I think it's better to have the default behaviour that has as
> little "clutter" as possible (_ip.system etc.).
Fixing a bug is obviously an improvement. The raw change can go
either way, since there are cases (such as when a prefilter cleans up
input) where the filtered history may be what you want. All I'm
saying is that it's not an *unconditional* improvement: it is better
in some cases, worse in others. In such a scenario, then we stick to
the existing behavior. But let's not change anything here again, I'm
just explaining policy for the long term.
> > 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.
> Justification in this particular case is that %hist is an interactive
> command, and as such unlikely to break scripts. In most "daily usage"
> scenarios it should be a net win. I'm reluctant to talk about
> "backwards compatibility" when we are dealing with interactive stuff.
People use ipython to write .ipy scripts now, so the behavior of
interactive commands *IS* part of what we have to worry about in terms
of backwards compatibility. Imagine if the standard unix command-line
utilities changed their flags and default behavior on every release.
We'd all have gone bonkers by now. I'm sure they *do* change, and
they break stuff, but the less that happens, the happier we'll all be.
More information about the IPython-dev