[IPython-dev] Python-based configuration system

[Ville Vainio]

Fernando Perez wrote:

> The work isn't hard, it's just a matter of going through the hairball 
> of the current code and ripping out all the deadwood.  The issue is 
> just one of time, not of difficulty.  Nothing in ipython is actually

I thought config rehaul would have been quite easy on the 
deadwood-ripping department, most of the work being localized on 
ipmaker.py. Though I admit it's rather tedious, because one would have 
to construct the new config files too. And there's that DPyGetOpt stuff 
as well, which, as you have said, should be replaced by optparse (or 
Optik if/when you insist on pre-2.3 backwards compatibility).

I would perhaps choose a more laissez-faire approach to configuring with 
command line parametes, though - just check that the var exist in the 
config dict, if it doesn't, complain. This would mean that "short" 
options as aliases for full names weren't supported, but it would ease 
maintenance a bit.

> 2. Write a multithreaded version of ipython like the interactive.py 
> from matplotlib I recently posted.  Sorry about this, but I won't move 
> forward until I can do this, since: a) I promised it already to others 
> b) I also need it for my own work.
>
> If you think you can/want to pitch in with 2, that would be _great_.  
> If not, and you don't want my

Well, 2. seems rather dependency-involved, which means more tedious 
testing, so I don't know whether I have the time/energy to directly help 
codewise (I'm supposed to have a summer holiday & all ;-). I agree about 
the need to do it first after 2.6.1.

The code you posted previously seemed to be ok, and not-hard to 
integrate with IPython. The way I would go about it (which would be 
usable in future too) would be to create a new class:

class ExecutionContext:
  run (cmd)  
  # blocks until cmd is done, returns the return value. Normal impl is 
trivial, in multithreaded case you
  # "feed" the cmd to that thread of yours and wait till it's done

  trycomplete(text)
  # asking the context for completions makes IMO more sense than asking 
for direct dicts


This would also be a better "one place to look" for the actual 
evaluation than separate funcs in the same class...

> 3. By the time we put out 0.6.2 with the multithreaded ipython 
> included, we'll flush out any bug reports which may have come from 
> 0.6.1, esp. about pysh. This can then be considered 'end of the road' 
> for the current codebase.
>
> At this point we can start really tearing the code, chainsaw in hand.
>
> How does that sound?

Reasonable :-). I guess I could help with some of the chainsawing, 
though I'm afraid my freetime will evaporate before that.

But now, off to finalizing that @bookmark system...