[IPython-dev] Python-based configuration system
vivainio at kolumbus.fi
Wed Jun 30 13:47:31 EDT 2004
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:
# 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
# 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...
More information about the IPython-dev