Yesterday I realized that there will be substantial problems using the
IPython code base, for reasons that have nothing to do with the code, and
everything to do with how people use IPython.
I am tempted to give a motivating example first, but in the interest of
"tell em what you're going to tell em" I'll state my conclusions first:
1. The IPython environment is more different from a plain Python
environment than I have realized.
Indeed, IPython is constantly creating "live" objects in its namespace.
2. This difference must be confronted if there is *any* hope of making Leo
an IPython notebook.
3. IPython namespaces suggest new Leo node types and directives.
Whether these will worthwhile remains to be seen: they are for discussion
only.
4. It is the IPython environment, not clever code, that makes IPython's
code completion so effective.
===== Motivating example: code completion
The above Aha's came directly from reading the docstrings in two IPython
files: completer.py and completerlib.py. Here is the start of the
module-level docstring for completer.py:
"This module is a fork of the rlcompleter module in the Python standard
library."
Oops! Reusing this module is going to difficult, if not impossible. Leo's
body pane does not use readline!
More interestingly, a little later the same docstring says:
QQQ
It's very cool to do "import string" type "string.", hit the completion key
(twice), and see the list of names defined by the string module!
...
The evaluation of the NAME.NAME... form may cause arbitrary application
defined code to be executed..
QQQ
But of course! In my study of the IPython code I have been reminded
constantly that the IPython namespace is continually updated (or polluted
:-) with new values. That's what cells do!
So to do code completion, IPython merely evaluates the "head", and calls
something like inspect to find the possible members of the head object.
**Important**: Leo does *exactly* the same thing, but only for certain
known values, like c and g, and for certain "standard" conventional names,
such as s, s1 and s2 standing for strings, etc.
===== Possible new @x nodes & directives
1. @completion-namespace
The body text of this node would be be evaluated to create a namespace used
when doing code completion. Like:
import string
or more interestingly:
c.p.u = 'import all stdlib'
This would tell Leo to automagically import all (or a designated set) of
Python's standard library when creating the completion namespace.
If the @completion-namespace node appears in @file foo.py, the body text
might contain
c.save()
try:
import foo
import imp
imp.reload(foo)
except ImportError:
pass
which would ensure that the latest text of foo.py is used when computing
completions.
2. @ipython-namespace <name>
This is pure blue sky. The idea is to allow a single .leo file to
represent one or more IPython notebooks with their associated namespaces.
This might be a Leo directive, rather than a node type.
The idea is that Leo's execute-script command might alter a given
namespace, rather than use a clean namespace as is typically the case.
===== Summary
**Important**: I am *not* merely proposing bizarre new IPython-related
features. Instead, I am pointing out the big difference between the
IPython and Leo.
In IPython, everything happens in the context of a namespace, that is, an
evolving set of live objects. In Leo, live objects are not typically
available. Yes, Leo uses live objects when completing special-case code,
but this is pretty much a kludge. More usually, Leo views the contents of
nodes as merely static text.
If there is *any* chance of Leo evolving into an IPython notebook (I have
real doubts), Leo must be able to represent IPython-like namespaces. The
proposals for new node types or directives are merely first ideas.
Otoh, reading the IPython docstrings suffices to explain why IPython can do
so much better at code completions than most IDE's. Everything is
(relatively) easy when live objects can be inspected.
Thus, the way to improve Leo's code completion is to use Leo's *existing*
completion code, augmented with more objects! @completion-namespace nodes
are one possible way to make live objects available to the completer.
Presumably, @completion-namespace nodes are about a safe as @script nodes,
that is, extremely unsafe if they come from an unknown source.
Your comments, please.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
