Show More
@@ -1,58 +1,24 b'' | |||||
1 | """Analysis of text input into executable blocks. |
|
1 | """Input handling and transformation machinery. | |
2 |
|
2 | |||
3 |
The |
|
3 | The first class in this module, :class:`InputSplitter`, is designed to tell when | |
4 | input from either interactive, line-by-line environments or block-based ones, |
|
4 | input from a line-oriented frontend is complete and should be executed, and when | |
5 | into standalone blocks that can be executed by Python as 'single' statements |
|
5 | the user should be prompted for another line of code instead. The name 'input | |
6 | (thus triggering sys.displayhook). |
|
6 | splitter' is largely for historical reasons. | |
7 |
|
7 | |||
8 | A companion, :class:`IPythonInputSplitter`, provides the same functionality but |
|
8 | A companion, :class:`IPythonInputSplitter`, provides the same functionality but | |
9 | with full support for the extended IPython syntax (magics, system calls, etc). |
|
9 | with full support for the extended IPython syntax (magics, system calls, etc). | |
|
10 | The code to actually do these transformations is in :mod:`IPython.core.inputtransformer`. | |||
|
11 | :class:`IPythonInputSplitter` feeds the raw code to the transformers in order | |||
|
12 | and stores the results. | |||
10 |
|
13 | |||
11 | For more details, see the class docstring below. |
|
14 | For more details, see the class docstrings below. | |
12 |
|
||||
13 | Syntax Transformations |
|
|||
14 | ---------------------- |
|
|||
15 |
|
||||
16 | One of the main jobs of the code in this file is to apply all syntax |
|
|||
17 | transformations that make up 'the IPython language', i.e. magics, shell |
|
|||
18 | escapes, etc. All transformations should be implemented as *fully stateless* |
|
|||
19 | entities, that simply take one line as their input and return a line. |
|
|||
20 | Internally for implementation purposes they may be a normal function or a |
|
|||
21 | callable object, but the only input they receive will be a single line and they |
|
|||
22 | should only return a line, without holding any data-dependent state between |
|
|||
23 | calls. |
|
|||
24 |
|
||||
25 | As an example, the EscapedTransformer is a class so we can more clearly group |
|
|||
26 | together the functionality of dispatching to individual functions based on the |
|
|||
27 | starting escape character, but the only method for public use is its call |
|
|||
28 | method. |
|
|||
29 |
|
||||
30 |
|
||||
31 | ToDo |
|
|||
32 | ---- |
|
|||
33 |
|
||||
34 | - Should we make push() actually raise an exception once push_accepts_more() |
|
|||
35 | returns False? |
|
|||
36 |
|
||||
37 | - Naming cleanups. The tr_* names aren't the most elegant, though now they are |
|
|||
38 | at least just attributes of a class so not really very exposed. |
|
|||
39 |
|
||||
40 | - Think about the best way to support dynamic things: automagic, autocall, |
|
|||
41 | macros, etc. |
|
|||
42 |
|
||||
43 | - Think of a better heuristic for the application of the transforms in |
|
|||
44 | IPythonInputSplitter.push() than looking at the buffer ending in ':'. Idea: |
|
|||
45 | track indentation change events (indent, dedent, nothing) and apply them only |
|
|||
46 | if the indentation went up, but not otherwise. |
|
|||
47 |
|
||||
48 | - Think of the cleanest way for supporting user-specified transformations (the |
|
|||
49 | user prefilters we had before). |
|
|||
50 |
|
15 | |||
51 | Authors |
|
16 | Authors | |
52 | ------- |
|
17 | ------- | |
53 |
|
18 | |||
54 | * Fernando Perez |
|
19 | * Fernando Perez | |
55 | * Brian Granger |
|
20 | * Brian Granger | |
|
21 | * Thomas Kluyver | |||
56 | """ |
|
22 | """ | |
57 | #----------------------------------------------------------------------------- |
|
23 | #----------------------------------------------------------------------------- | |
58 | # Copyright (C) 2010 The IPython Development Team |
|
24 | # Copyright (C) 2010 The IPython Development Team |
General Comments 0
You need to be logged in to leave comments.
Login now