[IPython-dev] [Ipython-svndiff] 2717 - improve callable alias inspection
Ville M. Vainio
vivainio at gmail.com
Thu Sep 6 12:06:08 EDT 2007
On 9/6/07, Fernando Perez <fperez.net at gmail.com> wrote:
> > 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.
No, that invocation would be enough to silence it forever (see how it
puts the flag in db). I.e. every user would initially be capable of
seeing what exactly went wrong, and they can easily opt out from
seeing the exceptions whenever they want.
> 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.
In my experience, when a completer raises an exception that is
supressed, it won't work. The only difference between a completer that
shows the exception and completer that doesn't is the fact that if the
exception is shown, the user will know there is a bug - otherwise, the
user will be left scratching their heads wondering why they won't get
It'd be good to know what the problematic cases are (when not showing
the exception would be a good thing), and target those specifically.
> 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.
Usually, the except clauses do something useful instead of merely
supressing the exception. This was not the case with completer.
> 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.
I don't see a need for this, really.
> 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
I think what would be enough for us is:
- Find every naked non-trivial "except"
- Add 'dump_exception("completer"),
dump_exception("inspect_indexcheck") etc., according to the exception
- implement dump_exception that will log / print / supress the
exception, based on config. In addition to supressing all excs, it
would be possible to do
This is certainly not 0.8.2 stuff, of course.
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
More information about the IPython-dev