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

[Ville M. Vainio]

On 8/7/07, Fernando Perez <fperez.net at gmail.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.).

> 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.

I am not opposed to adding -t as default option to %hist in ipy_legacy.py.

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

I had no intention of breaking the profiles; in fact, after a hurried
svn up at work I thought it was a new file (even as only the profile
was new).

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'