roadmap.txt
73 lines
| 2.2 KiB
| text/plain
|
TextLexer
Brian E Granger
|
r1256 | .. _roadmap: | ||
=================== | ||||
Development roadmap | ||||
=================== | ||||
Brian Granger
|
r2197 | IPython is an ambitious project that is still under heavy development. | ||
However, we want IPython to become useful to as many people as possible, as | ||||
quickly as possible. To help us accomplish this, we are laying out a roadmap | ||||
of where we are headed and what needs to happen to get there. Hopefully, this | ||||
will help the IPython developers figure out the best things to work on for | ||||
each upcoming release. | ||||
Brian E Granger
|
r1256 | |||
Brian Granger
|
r1790 | Work targeted to particular releases | ||
==================================== | ||||
Brian E Granger
|
r1256 | |||
Brian Granger
|
r1790 | Release 0.11 | ||
------------ | ||||
Brian E Granger
|
r1256 | |||
Brian Granger
|
r2197 | * [DONE] Full module and package reorganization. | ||
* [DONE] Removal of the threaded shells and new implementation of GUI support | ||||
based on ``PyOSInputHook``. | ||||
Brian E Granger
|
r1256 | |||
Brian Granger
|
r2197 | * Refactor the configuration system. | ||
Brian Granger
|
r1792 | |||
Brian Granger
|
r2197 | * Prepare to refactor IPython's core by creating a new component and | ||
application system. | ||||
Brian E Granger
|
r1256 | |||
Brian Granger
|
r1790 | Release 0.12 | ||
------------ | ||||
Brian E Granger
|
r1256 | |||
Brian Granger
|
r1792 | |||
Brian E Granger
|
r1256 | |||
Brian Granger
|
r1790 | Major areas of work | ||
=================== | ||||
Brian E Granger
|
r1256 | |||
Brian Granger
|
r1790 | Refactoring the main IPython core | ||
--------------------------------- | ||||
Brian E Granger
|
r1256 | |||
Brian Granger
|
r1790 | Process management for :mod:`IPython.kernel` | ||
-------------------------------------------- | ||||
Brian E Granger
|
r1256 | |||
Brian Granger
|
r1790 | Configuration system | ||
-------------------- | ||||
Brian Granger
|
r1677 | |||
Brian Granger
|
r1790 | Performance problems | ||
-------------------- | ||||
Brian E Granger
|
r1256 | |||
Currently, we have a number of performance issues that are waiting to bite users: | ||||
Brian Granger
|
r1790 | * The controller stores a large amount of state in Python dictionaries. Under | ||
Brian Granger
|
r1766 | heavy usage, these dicts with get very large, causing memory usage problems. | ||
We need to develop more scalable solutions to this problem, such as using a | ||||
sqlite database to store this state. This will also help the controller to | ||||
be more fault tolerant. | ||||
Brian Granger
|
r1790 | |||
Brian Granger
|
r1766 | * We currently don't have a good way of handling large objects in the | ||
controller. The biggest problem is that because we don't have any way of | ||||
streaming objects, we get lots of temporary copies in the low-level buffers. | ||||
We need to implement a better serialization approach and true streaming | ||||
support. | ||||
Brian Granger
|
r1790 | |||
Brian Granger
|
r1766 | * The controller currently unpickles and repickles objects. We need to use the | ||
[push|pull]_serialized methods instead. | ||||
Brian Granger
|
r1790 | |||
* Currently the controller is a bottleneck. The best approach for this is to | ||||
separate the controller itself into multiple processes, one for the core | ||||
controller and one each for the controller interfaces. | ||||
Brian E Granger
|
r1256 | |||