Re: InterpreterPasteInput.py => ipy_interpreter_paste.py

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterPasteInput.py => ipy_interpreter_paste.py

Fernando Perez
On 8/7/07, Ville M. Vainio <[hidden email]> 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
_______________________________________________
IPython-dev mailing list
[hidden email]
http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterPasteInput.py => ipy_interpreter_paste.py

Ville M. Vainio
On 8/7/07, Fernando Perez <[hidden email]> 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'
_______________________________________________
IPython-dev mailing list
[hidden email]
http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterPasteInput.py => ipy_interpreter_paste.py

Fernando Perez
On 8/7/07, Ville M. Vainio <[hidden email]> wrote:

> On 8/7/07, Fernando Perez <[hidden email]> 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.


Cheers,

f
_______________________________________________
IPython-dev mailing list
[hidden email]
http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev