[IPython-dev] [Ipython-svndiff] 2717 - improve callable alias inspection

[Fernando Perez]

On 9/6/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 9/6/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > > Yes, and it's a pain :->. It's preventing the completion to work on quite
> > > a few objects.
> >
> > Feel free to fix it, since it's a bug.  That's what commit rights are for :)
>
> "Errors should never pass silently, unless expicitly silenced"
>
> That is, the exceptions in completer should show show the invocation
> to silence them for good. That way, users that are bothered by them
> can supress them, but we would still get bug reports for surprising
> exceptions.
>
> I'm thinking of something like "Enter _ip.db['no_completer_exc'] = 1
> to never see these again".

Yes, ideally we'd have something like that (but see below for more),
so that users and developers can easily toggle it, or permanently set
the flag in their config file if they are not interested in seeing the
errors ever.

But in the meantime, this is a case of 'practicality beats purity':
early raising  means that having a broken object in your namespace
(not broken code in ipython, but some object that does something
outright wrong) will basically stop completion from working.  That's
the case Gael complains about, and that has bothered me and others in
the past.

But if we are going to enable control over internal exception
silencing, it shouldn't be specific to completion,  that happened to
be a case I mentioned.  The grep I showed has 114 bare 'except:'
clauses in the code, and probably many of those are of a similar
nature to this situation, where we are hiding potentially useful
information for the sake of making day to day use less annoying.

So the right solution is to have the option to control internal
exception swallowing.  Users interested in helping provide details
could then toggle this

internal_verbose_exceptions

flag to True and start seeing lots more detail, while the rest (the
majority of users do not write bug reports, though we are very
fortunate to have many who indeed are an educated bunch who take the
time to do so) can have a day to day ipython that isn't constantly
showing internal details.

If this is implemented, we should only default it to True initially on
an SVN release, to test out with more willing users how annoying it
becomes in practice.  Defaulting it to True would be in line with the
idea of 'explicit errors', but I'd like some feedback from day to day
use before activating that kind of radical change.  114 is a lot of
chances for new tracbacks to start showing up, and we don't want all
of a sudden for people to think that 'ipython broke' because it begins
to show lots of frequent error messages.

If you decide to impmlement this, let's talk about how to do it right
before  committing to an approach.  Gael mentioned Enthought's traits
approach, but that may be more than we need in this case (it looked
good but like a rather sophisticated solution that may be overkill for
us).

cheers,

f