Cython has no place in Leo

[Edward K. Ream]

The situation has, at last, become clear. Let us suppose, contrary to
expectation, that it *were* possible to translate all or part of Leo
into Cython, such that the resulting code was:

A. As safe as Python, and

B. At least 10 times (or more) faster than the Python code it
replaces, and

C. A result (somehow!) of a common *Python* code base.

The question is, would the resulting Cython code be useful? Imo, the
answer is an emphatic "no", for at least three, no four, reasons:

1. There is no part of Leo for which a 10x speedup would make a
substantial difference.

Moreover, I do not believe that rewriting, say,
leo.core.leoNodes.position class in Cython has any chance of improving
Leo. Even if the code took *zero* time to execute, the effect on Leo
would be minimal.

2. Replacing Python with Cython would hinder development and make Leo
less flexible.

Cython code can not easily be patched or extended from Python. Cython
would ossify Leo, exactly the opposite of what we want.

3. Distributing (or generating) Cython code with would complicate
distribution issues.

The average user has *no chance* of using Cython in the Windows and
Mac environment. Setting up Cython on those platforms would be a
horror show. This situation is easier in Ubuntu/Linux, but newbies
have enough distribution problems, thank you very much, without
throwing Cython into the mix.

4. Even if a common code base were possible, it would not be as simple
as the present code base, and the (somewhat magical) tools required to
maintain the code base would themselves represent a drag on
development and maintenance.

This should end a whole lot of speculation. As a result of these
insights, the py2cy project is dead. It died peacefully :-) I plan
no further work on any scheme that translates Python into something
else.

My plan now is to put the super-lint project on the shelf for at least
a week or two: there are lots of items in the Leo world to attend to.

Edward

P.S. Apparently, any significant enhancements to Python's speed will
have to come from within the Python project itself. Perhaps the pypy
will be the route. In any event, there nothing to be done here.

P.P.S. I consider the last few day's discussions, musings and
fumblings to an example of a *successful* design project, for two
reasons:

1. Massive confusion has been replaced by a clear, unambiguous
result. I'll probably make a FAQ entry to remind myself not to bother
thinking about "improving" Python :-)

2. No code was prematurely written, so no code has been wasted. This
is as it should be, but often is not.

EKR

[Ville M. Vainio]

On Wed, Apr 13, 2011 at 7:02 PM, Edward K. Ream <edre...@gmail.com> wrote:

> 1. There is no part of Leo for which a 10x speedup would make a
> substantial difference.

I thought of the same thing earlier. The fact that there is no clear
part of Leo where speedup would be badly needed is a happy "problem"
to have. The only place I could think of is saving a file.

(Contrast this with pre-Qt era where overall feeling of Leo was that
of sluggishness..).