Python on NB?

[Ridgeglider]

Does anyone have any idea whether it's possible to get Python running on the NB, ideally as as standalone task beside the other regular ones so there could be some interpretive debug / quick try setup available?

Python can be pretty handy...

[bbracken]

When the NB modules run linux... you'll have python.

bb

[Ridgeglider]

Well, yes, that's true; I was hoping there might be another option w/o linux.... I know Paul asked about interest in this a few years ago. Not sure if anything came of it.

[dciliske]

The idea is still being kicked around, but as of yet nothing's materialized.

[Ridgeglider]

I think it’s interactivity would be really helpful in bringing up quick prototypes. Also, it’s string handling abilities are really great. If there is a way to make it's interpreter coexist with the rest of the C/C++ functionality it would be a great tool.

[dciliske]

I'm curious what you would think about using a Python to C++ cross compiler.

It appears that ShedSkin does a fairly good job, but uses a restricted subset of Python.

[Ridgeglider]

I took a quick look at the ShedSkin approach. Here are my thoughts. I'm interested in Python for two reasons. Both are related to, and I believe build on why the NB platform is already such a good value. Plainly, the NB bundle of hardware, software, documentation, examples and the consistently improving stable releases make it possible to implement, as the motto says, "Networking in one day." That's quite a feat that's made possible because the tools manage a good balance of being both superb prototyping tools, as well as devices that carry well into production. So, Bravo!

However, there is a big part of prototyping that benefits from interactive, what-if experimentation that might eventually lead to a more focused design spec.: what should the user interface look like? How do you talk to certain hardware? I think an NB Python port might be a way to really improve that early exploration into products; that stage when you are defining what's possible. Python's interactive, interpretive features are really great for exploring and defining these kinds of issues. One part of this interactivity is the way it handles untyped data, and in particular, lists. In looking at ShedSkin, it appears that all of this interpretive interface is eliminated. So too is the flexible, untyped way Python handles lists and dictionaries.

NB's are great because they support lots of communication channels: serial ports, i2c, spi, UDP, TCP, etc. Python, and particularly its lists and dictionaries provide really great tools for parsing, searching and filtering data coming over these channels, making decisions and outputting responses over different channels. It's true that the interpretive calls can be slower than compiled code, but Python also provides ways to execute compiled code once it's been processed by the interpreter.

Finally, I can't tell you how many times I've written what amount to C/C++ case statements that trigger certain functions, or certain versions of functions in response to simple serial commands during development. On the current NB [platform, this is all you get for interactivity! Python has the potential to eliminate this approach. The ideal would be a way for Python to call C/C++ functions, and for C/C++ to call compiled PYC Python code.

So, this is a long-winded way of saying thanks for exploring how to bring up Python on NB, but, in my opinion, ShedSkin is not the answer: it doesn't offer any interpretive/interactivity, and Python's flexibility (and I'm sure some will say danger of) untyped objects is eliminated. I don't see why we'd use it instead of the existing C/C++ tools. It's only advantage is for those people who are not comfortable, or would not choose to do programming in C/C++. However, that's not why I'd have an interest in Python.

[dciliske]

Actually, that is a very good series of points to make and exactly the concerns that I came across while thinking about it further last night. If we do head down that path at some point, it'll have to be after taking a good hard look at what the right way is to port the interpreter and wrap C/C++ libraries.

[tony]

I think that the full Python stack might be a stretch for the Netburner products. You might want to look at an embedded subset http://wiki.python.org/moin/PyMite. I know a lot of electronics companies use Lua in their microcontroller projects. There is the embedded Lua project http://www.eluaproject.net/ which might be more useful if your not exclusively thinking of using the Python language. They don't currently support the Coldfire controllers but I'm sure the code there would give you a pretty good start. The nice thing about this project is that it is focused on embedded so they have code to support I2C, SPI, etc..... Maybe Netburner could even donate some hardware to them to get a port done!!! There was a post by one of the ELua maintainers http://lua-users.org/lists/lua-l/2010-07/msg00748.html stating that there was some Coldfire interest in the past. I think you will find that it is much easier to get Lua up and running than it would be to get Python going.

I haven't played around with my Netburner hardware in a very long time. If I get a chance in the future maybe I'll take a look at this as well. If I had to start I would grab the sources from ELua and Lua base then run them through WinMerge to see what they have done to customize it. I would then try to compile the base Lua files using the Netburner tools to see what (if anything) fails and go from there............

[dciliske]

I've been taking a look at this a fair bit over the last month. The result is that I've gotten a Lua interpreter and shell up and running on the board, but without any real capabilities (no interface to the NB libraries...), is completely untested (Does it crash? How much memory does it use? How fast is it?), and may require some major changes, if it is to be properly integrated. It is using the standard Lua license (MIT License), and an optional utility using the 2-clause BSD License.

On the Python front, has anyone taken a look at the utility Cython? It's ostensibly designed for creating c based python libraries, but it does create C code that can be compiled.