[IPython-dev] Jython support in ipython

[Jim Baker]

On Fri, Oct 22, 2010 at 5:35 PM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 23 October 2010 00:04, <ipython-dev-request at scipy.org> wrote:
>
>> Trying a little bit more by disabling that version check, I discovered
>> that
>> at least 2.6's support of print as a function, instead of a statement, is
>> used. Now Jython 2.6 work kicked off just this week, so hopefully we don't
>> really need 2.6. Jython 2.5 does have two key 2.6 features that you might
>> be
>> using: 1) full mutable ast support (through the ast module, used by
>> sympy's
>> support); 2) class decorators. (We also have namedtuple.)
>>
>> Maybe for Jython this is just a matter of isolating the print function? It
>> doesn't seem to be used in too many places.
>>
>
> Just to chime in here, we have been working on the principle that ipython
> 0.11 would depend on Python 2.6 or later, and I've been 'modernising' the
> code base a bit, to fit in with my Python 3 branch of ipython. I'm sorry if
> this makes your life harder. Off the top of my head, though, I think most if
> not all of my changes should be compatible with 2.5.
>

Sounds reasonable to have a small compatibility shim then for 2.5. The other
piece I've found so far is switching from compiler to _ast (assuming CPython
2.5 compliance of course); neither Python 3 nor Jython supports the
old-style syntax tree. Casually inspecting the usage of the compiler module
suggests that there's not much use. In core, kernel.core.interpreter and
core.inputsplitter seem to have significant code duplication in their use of
compiler to get line numbers. We do support codeop, so that should work as
soon as it's made valid for future imports.

Incidentally the problem I noticed earlier in parsing a statement like
"print 42" was with codeop.CommandCompiler, not the compiler module.
Apparently ipython expects CPython's behavior of
codeop.CommandCompiler().compiler.flags, which is an int, whereas Jython has
this as codeop.CommandCompiler()._cflags, which is a structure. Strange, I
thought this was being exposed as an int for compatibility in this fashion.
Maybe we should fix that part for 2.5.2rc2. I'll take a look at it.

- Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101022/5c921383/attachment.html>