[IPython-dev] InterpreterPasteInput.py => ipy_interpreter_paste.py
Ville M. Vainio
Tue Aug 7 13:06:11 CDT 2007
On 8/7/07, Fernando Perez <firstname.lastname@example.org> 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
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
More information about the IPython-dev