Anyone for Python? (thinking out loud...)

[SimplSam]

In summary - I would love Python 3.x to be added to Moho as a 2ndary scripting language, with access to all the same application bindings as LUA.

Python is like a zillion times more extensive and extensible than our embedded Lua, with lots of ready-made well tested addons & scripting examples and is very widely used both inside and outside of the Graphics/Animation industry. Lots of cool code & coders out there.

This type of dual script language setup is used in products like Davinci Resolve and seems to work very well.

Just to clarify - I certainly do not want to replace Lua (it is my friend), but just feel it could do with a buddy to help it out every now and then - particularly when wanting to interface with data and systems.

[Daxel]

If this is possible and not very hard to do, it could be a very good idea. Scripts improve Moho a lot, and being able to write them using the (probably) most popular programming language would mean a lot more scripters in the community. I'm trying to dive into programming and I'm learning python.

[synthsin75]

For embedded scripting languages, Lua is smaller and faster than Python. That is pretty important when you have tools that need to repeatedly call their functions while moving a mouse, etc.. In some cases, Moho can already become sluggish, so I doubt we really want anything that could make it even slower.

Much less the added burden on the developers.

If neither of those were a factor, I'd be all for it.

[SimplSam]

Given modern processing - I would like to think the speed difference between the languages is not that significant for most GUI related tasks - and there are also many examples of high performance graphics/animation applications with python powered UI's.

But, in any event - I think I would agree that the core GUI tools should remain Lua - which would alleviate the concerns of performance and maintainability.

The real driver for this addition & change - would be extensibility. Once you try to extend beyond the core Moho functionality (getting outside of the box), you start hitting multiple issues, mainly due to the limited feature set of the core Lua distribution. Even something ridiculously simple like checking the last modification timestamp on a file is not possible in the standard Lua distro !!

p.s. I just compared the size of the standard LUA and Python windows distributions - and Python is about 60x bigger!!

[synthsin75]

The real driver for this addition & change - would be extensibility. Once you try to extend beyond the core Moho functionality (getting outside of the box), you start hitting multiple issues, mainly due to the limited feature set of the core Lua distribution. Even something ridiculously simple like checking the last modification timestamp on a file is not possible in the standard Lua distro !!

That's why I've done a lot that is Windows-only, so I can use the command line.

[hayasidist]

... Even something ridiculously simple like checking the last modification timestamp on a file is not possible in the standard Lua distro !!

For Windows: This only gives you time to the HH:MM precision but...

Code: Select all

	local path = [[C:\Users\Paul\Documents\]] -- e.g.
	local dirOut = io.popen( "dir /T:A /-C /A-D " .. path .. "*.*", "r" )
	local dirData = dirOut:read "*a"

loads up dirData with the directory listing giving one line per file:
((header))
date and time last accessed, file size, file name
((footer))

which you can then parse..

and all this is callable from a Moho script...

What it does is: popen invokes the command line to run the DIR program with the switches, path and filename given
then the read *a returns the whole output in one go...

(Lua manual http://www.lua.org/manual/5.2/manual.html#6.4)

which may or may not help...

[SimplSam]

I certainly have had my fun with os.execute and io.popen, complete with their (bearable & unbearable) pop-up command prompts on Windows, and equally understand what must be done when needs must.

One of the primary aims of my post was to look towards an alternative future - where we don't have to invest time integrating with low-level interfaces, and can instead focus our skills & attentions on developing and exploiting class leading applications & extensions.

[Rai López]

In kind of a secret way, this always has been one of my favorite whishes about Moho and programming. As much as I learned to love Lua, Python is the standard out there when it comes to animation but not only that, and it brings much more possibilities due to it's evolution and libraries. Plus, if you learn Python, you well could be forging a future without even notice, whereas with Lua the market is much more limited, even I'd dare to say a niche. Unfortunately, I think this is one of those things that we'll probably never see implemented due to I'm sure there are other priorities and totally I understand it, so that's why I said I've always wanted this "secretely". But well, just my thoughts and who knows...

[hayasidist]

Agreeing with Wes and Ramon, if the choice is improved core Moho or adding python bindings for what's already there it's pretty evident which should have first call on the resources available to do the work ...

However, if the longer term strategy for Moho (perhaps V14 or V15 or beyond) were to be to migrate it's "outsides" to python I'm confident that the decision would consider, amongst other issues such as performance, balancing ease of implementing "new stuff" versus cost of migrating existing LUA stuff to python -- total guesswork here - say 100,000 lines of LUA code in the factory-provided tool and menu scripts plus, of course, all the user-contributed scripts (not included in that guesstimate). Personally speaking, if such an announcement were to be made with sufficient notice so that scripters had time to adapt to the change, it would not bother me at all. And if a python binding fell into my lap alongside the LUA one that would be ok too.

IMO, the "niche" isn't the language - LUA and python are sufficiently similar that any programmer who knows one will find it very easy to become fluent in the other -- sure there are differences, some significant, some mere irritations - e.g. in what circumstances does an index start at 0 or 1 .. And yes, there are more Python libraries out there than LUA ones.

Rather, IMO, the marketable Niche is familiarity with how to drive the interface to the application.. for example, if I asked someone to write code to draw both a circle and a sphere in both Moho and Blender the challenge wouldn't be knowing LUA or python it would be understanding how to tell the program where to put the points / verts, how to connect them together, how to create shapes / faces and how to define the materials...

so back to the main point: Right now Moho is a LUA environment. Without hesitation there are some facilities that could be added to Moho (along with interface routines) that would make life a whole lot easier for users and for scripters. And as well as the Moho specific ones, I'm sure that other, more general ones could be useful - access to information about a file being one case in point. So, until Moho transcends to Python I think there are two distinct approaches: (re-)write any critical essential functions in LUA (e.g. as outlined above); or provide interface routines to run python functions from LUA (not something I've actually done, but the web seems to awash with ideas on how to accomplish that).

Another point that this thread has brought home to me is that we (the LUA community here) share our scripts but what we haven't yet done is modularise stuff with re-usability in mind -- IOW it seems that we (and I certainly do this!) re-use code by including it in-line rather than creating a set of generic LUA "library functions" for oft-used code... I'm now pondering how to make a start on capturing stuff that is generally useful but that every script writes from scratch ...