[IPython-dev] Jython support in ipython

[MinRK]

On Fri, Oct 22, 2010 at 18:30, Jim Baker <jbaker at zyasoft.com> wrote:

> 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.
>>
>
One 'modern' codestyle that is not compatible with 2.5:
try:
   stuff()
except Exception as e:
   handle(e)

That's invalid on 2.5, but 'except Exception, e:' is invalid on 3.x.

The only method that I have discovered that works on both is:

try:
  stuff()
except Exception:
  e = sys.exc_info()[1]

Obviously not as elegant as either one, but if you are supporting 2.5 and
3.1, it's the only way that works that I know of.
That's what I do in my 'nowarn' branch of pyzmq, which works (as of
yesterday) on everything from 2.5-3.1 with no code changes.

-MinRK



>
> 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
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101022/11ae2833/attachment.html>