Managing Python 2.7 Code In Leo

[tbp1...@gmail.com]

Now that Leo is Python 3.6+ only, there is a question about using it to maintain old Python 2.x code, of which I have some that can't be converted to Python 3.6+.  The issue, of course, is that checkers like flake8 will report errors which aren't actual errors for 2.7 code.  This is a best a nuisance and at worst might lead to failure to save files.

What's the best way to handle these older Python files in Leo?

[Edward K. Ream]

On Sun, Jan 16, 2022 at 12:20 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

Now that Leo is Python 3.6+ only, there is a question about using it to maintain old Python 2.x code, of which I have some that can't be converted to Python 3.6+.  The issue, of course, is that checkers like flake8 will report errors which aren't actual errors for 2.7 code.  This is a best a nuisance and at worst might lead to failure to save files.

What's the best way to handle these older Python files in Leo?

Convert them to python 3.x.

Edward

[tbp1...@gmail.com]

Can't do it for at least one case.  The code is Jython 2.7, and it will be a long time, if ever, before Jython gets up to 3+.

[tbp1...@gmail.com]

The project is a Tomcat web application that uses mixed java and Jython.  Most of the work is done with Jython, but there are some things that need java.  In some places, java code calls Jython objects and methods, in other places Jython code calls into java. It works great. I've been supporting and slowly developing this application since about 2007.  There is zero chance I would ever convert it to all java, that would be too unpleasant to contemplate (and my client would not want to cover the cost to do it).

[Edward K. Ream]

On Sun, Jan 16, 2022 at 3:08 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

The project is a Tomcat web application that uses mixed java and Jython. 

VSCode probably allows you to use python 2 for some projects. I am not going to support python 2 in Leo, but a plugin could do so.

Edward

[tbp1...@gmail.com]

Probably being able to disable automatic syntax checking in an outline would be enough.  Is there a setting to do that?

[Edward K. Ream]

On Mon, Jan 17, 2022 at 7:30 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

Probably being able to disable automatic syntax checking in an outline would be enough.  Is there a setting to do that?

@bool check-python-code-on-write

In future, please search for settings before asking about them.

Edward

[tbp1...@gmail.com]

That setting is not among the settings listed in the output of Settings/Show Settings/Show-Settings.  I now, after your post,  see that it is included in leoSettings.leo, where I had to try various guesses as to what the setting might be called before finally noticing it.  I started searching for "syntax", and eventually tried "check".

Seems to me that the menu item to show settings should at least show all of the ones in leoSettings.leo, if not more.

[David Szent-Györgyi]

Jython is one of the languages in which macros are written for the ImageJ image processing and analysis software, and important as such. Jython support for Python3 is planned and roadmapped. 

Another significant implementation of Python for which Python3 compliance is a work in progress is IronPython, which runs native on the Dynamic Language Runtime for .NET. The implementation is open source, source code for IronPython2, IronPython3, and the Dynamic Language Runtime is on GitHub. The current forum for for developers and users a Gitter discussion group. 

I work on ImageJ macros, using Jython when I can. I work with .NET-based applications for which IronPython is the macro language.  Those macros are short enough that they don't need an outliner, and the host applications provide the IDE. 

[tbp1...@gmail.com]

The Graal system can also run jython or jython-like code to some degree.  They added some improved support for inheriting from jython/pythonIntroduction to GraalVMclasses in java at my request.  See, e.g., Inheritance from Java.

In my case, I have to run under Tomcat.  It seems that Graal now supports/is supported by Tomcat to some degree at least:  GraalVM 20.0: Run Tomcat as Native Image on Windows.  It's a terrific accomplishment, but I seriously doubt that I could get my using agencies to start using Graal with Tomcat.  Still, it might be worth looking at for ImageJ.

For those not familiar with Graal, "GraalVM is a high-performance JDK distribution designed to accelerate the execution of applications written in Java and other JVM languages along with support for JavaScript, Ruby, Python, and a number of other popular languages. GraalVM’s polyglot capabilities make it possible to mix multiple programming languages in a single application while eliminating foreign language call costs." - Introduction to GraalVM.

The polyglot capability might make it really interesting for Leo if only it could support major Python libraries like QT, numpy, etc.  Here's someone showing the use of numpy with Graal: https://abvijaykumar.medium.com/building-graalvm-native-image-of-a-polyglot-java-numpy-application-a7288740409e, so maybe it can be done.  Wouldn't it be wonderful to mix java, Python, R, and javascript code in one Leo subtree, and execute it within Leo!

[tbp1...@gmail.com]

On Monday, January 17, 2022 at 12:57:12 PM UTC-5 David Szent-Györgyi wrote:

Jython support for Python3 is planned and roadmapped. 

Yes, and have you noticed the huge amount of work those plans will entail?  I don't see it getting competed in the near future, I'm sorry to say. 

[Edward K. Ream]

On Mon, Jan 17, 2022 at 9:10 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

That setting is not among the settings listed in the output of Settings/Show Settings/Show-Settings. 

[M] @  bool checkforchangedexternalfiles = True

The name shown is the "dictionary" name, with "-" and "_" deleted.

In any case, leoSettings.leo contains the primary data, and the data are organized by subject.

Edward

[David Szent-Györgyi]

Like you, I thought those plans call for a lot of work, and completion might be some time off. Part of that might be the ever-growing complexity of Python3, which is accruing features that cannot be implemented simply, thereby complicating maintenance of minority implementations such as Jython and IronPython. 

I greatly admire the tasteful engineering that I see in the choices that Guido van Rossum made in earlier releases. For example, an operating system that supports multi-tasking well relieves the need for multi-threading. 

For more straightforward scripting engine uses, there's always Lua, though the fork of Lua done to implement a JIT trails the main implementation. There is an interesting offshoot of the language that is aimed at systems programming. 

Yeah, yeah, I know, I'm wandering far afield, sorry for trespassing. I'll come quietly, officer! 

[tbp1...@gmail.com]

On Monday, January 17, 2022 at 12:57:12 PM UTC-5 David Szent-Györgyi wrote:

Jython support for Python3 is planned and roadmapped. 

Yes, and have you noticed the huge amount of work those plans will entail?  I don't see it getting competed in the near future, I'm sorry to say. 

Like you, I thought those plans call for a lot of work, and completion might be some time off. Part of that might be the ever-growing complexity of Python3, which is accruing features that cannot be implemented simply, thereby complicating maintenance of minority implementations such as Jython and IronPython. 

I greatly admire the tasteful engineering that I see in the choices that Guido van Rossum made in earlier releases. For example, an operating system that supports multi-tasking well relieves the need for multi-threading. 

I worry that Python has been adding too many complex features too quickly.  But then, I suppose you don't have to use them.

For more straightforward scripting engine uses, there's always Lua, though the fork of Lua done to implement a JIT trails the main implementation. There is an interesting offshoot of the language that is aimed at systems programming. 

Ah, Lua!  I think I last tried it back before I had even encountered  Python, but back then I didn't really have a need for it. Maybe I should revisit it.  I would want at least some equivalent for numpy and a gui system like Qt.  I gather that wxWindows is a possibility among others.

[David Szent-Györgyi]

On Monday, January 17, 2022 at 12:57:12 PM UTC-5 David Szent-Györgyi wrote:

For more straightforward scripting engine uses, there's always Lua, though the fork of Lua done to implement a JIT trails the main implementation. There is an interesting offshoot of the language that is aimed at systems programming. 

On Monday, January 31, 2022 at 12:04:25 PM UTC-5 tbp1...@gmail.com wrote:

Ah, Lua!  I think I last tried it back before I had even encountered  Python, but back then I didn't really have a need for it. Maybe I should revisit it.  I would want at least some equivalent for numpy and a gui system like Qt.  I gather that wxWindows is a possibility among others.

From a Web search for the words "Lua" and "Numpy":

Lua Equivalent for NumPy and SciPy? - Stack Overflow

Convert Torch Lua into Numpy Python - Stack Overflow

That spurs a search for the words "Torch" and "Lua", which is fruitful, if frustrating in the end. From the Wikipedia article on Torch: 
Torch is an open-source machine learning library, a scientific computing framework, and a script language based on the Lua programming language. It provides a wide range of algorithms for deep learning, and uses the scripting language LuaJIT, and an underlying C implementation. It was created at IDIAP at EPFL. As of 2018, Torch is no longer in active development. However PyTorch, which is based on the Torch library, is actively developed as of June 2021.

PyTorch has language bindings for Python and for C++. I read that there is information available on calling C++ functions from Lua, but I don't know how easy that is, given the reliance of C++ on mangling names. 

There's also SciLua, which I read is most easily installed with the ULua distribution of LuaJIT. I'm not sure that falling back on a specific distribution of a minority implementation of Lua promises greater ease than pursuing a minority implementation of Python, alas. 

More on Torch below. 

From Torch | Scientific computing for LuaJIT.:
Torch is a scientific computing framework with wide support for machine learning algorithms that puts GPUs first. It is easy to use and efficient, thanks to an easy and fast scripting language, LuaJIT, and an underlying C/CUDA implementation.

A summary of core features:

• a powerful N-dimensional array
• lots of routines for indexing, slicing, transposing, …
• amazing interface to C, via LuaJIT
• linear algebra routines
• neural network, and energy-based models
• numeric optimization routines
• Fast and efficient GPU support
• Embeddable, with ports to iOS and Android backends

From Lua and Torch - Artificial Inteligence - GitBook:
Torch is a scientific computing framework based on Lua with CPU and GPU backends. You can imagine like a Numpy but with CPU and GPU implementation. Some nice features:

• Efficient linear algebra functions with GPU support
• Neural Network package, with automatic differentiation (No need to backpropagate manually)
• Multi-GPU support
  

Lua Torch :: Anaconda.org

Get Lua running with Torch on Windows 10 with limited Admin rights - Stack Overflow

Lua & Torch Tutorial - luckylwk.github.io