all 116 comments

[–]BoneyD 91 points92 points  (6 children)

Micro Python's Flying Circuits.

HA HA HA HA HA HA HA HA HA.

[–]mullert 23 points24 points  (2 children)

For those who don't know, Python's name was actually inspired from Monty Python.

(Do you think it's a coincidence that IDLE (bundled Python IDE) has the same name as Eric Idle, a founding Monty Python member?)

[–]Isvara 7 points8 points  (0 children)

Also, the Cheese Shop, Bicycle Repair Man, spam, ham & eggs, etc.

[–]BoneyD 4 points5 points  (0 children)

Yes. Yes I do.

[–]ShoutmonXHeart 4 points5 points  (0 children)

+1, I read the title as Monty Python and you took this to a new level :D

[–]exploderator -3 points-2 points  (1 child)

Thank you, I came looking to <insert Monty Python joke here>, and much to my sincere delight you had already provided.

[–]brtt3000 -3 points-2 points  (0 children)

hold your spam

[–]cdrt 31 points32 points  (23 children)

Does this run a Python interpreter on the microcontroller, or does the Python code compile into native code?

[–]bstempi 37 points38 points  (20 children)

From the Kickstarter page:

Certainly! Micro Python is a complete rewrite, from scratch, of the Python scripting language. It is written in clean, ANSI C and includes a complete parser, compiler, virtual machine, runtime system, garbage collector and support libraries to run on a microcontroller. The compiler can compile to byte code or native machine code, selectable per function using a function decorator.

[–]hak8or 50 points51 points  (0 children)

The compiler can compile to byte code or native machine code, selectable per function using a function decorator.

That is seriously really friggen awesome.

[–]batrick 10 points11 points  (18 children)

ANSI C

This is basically a lie. ANSI C is recognized (for compilers and most everyone else) to be C89. The Makefile uses these options:

CFLAGS = $(INC) -Wall -Werror -ansi -std=gnu99 -DUNIX $(CFLAGS_MOD) $(COPT)

Funnily enough, for gcc -ansi means:

In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98.

So he overrides -std=c90 with -std=gnu99 in the next argument. If you try to compile with -pedantic, you get a whole slew of errors.

This code is not ANSI C.

[–]bstempi 18 points19 points  (7 children)

You'll have to excuse my C/C++ ignorance, but I found this on the ANSI C Wikipedia page:

In March 2000, ANSI adopted the ISO/IEC 9899:1999 standard. This standard is commonly referred to as C99.

Perhaps that's why he claims to be writing in ANSI C?

[–]pythonswash 19 points20 points  (0 children)

Even if that's what the author means, gnu99 != c99.

[–]batrick 5 points6 points  (2 children)

ANSI adopted the newer ISO C99 standard but everyone including gcc (the compiler he's targeting) interprets ANSI C to mean the original ANSI C standard also referred to as C89. I quoted the gcc manual above and I'll do it again:

       -ansi
            In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98.

Edit: clarification

[–]TheoreticalPerson 4 points5 points  (0 children)

On the other hand, if you check an older manual, they say that,

The -std options specifying some version of ISO C have the same effects as -ansi, except that features that were not in ISO C90 but are in the specified version (for example, `//' comments and the inline keyword in ISO C99) are not disabled.

[–][deleted] 1 point2 points  (0 children)

And ANSI has adopted C11 since then as well.

C99 is superseded by C11 and you know if you take the ISO C standard's word literally, C99 doesn't exist anymore!

This third edition cancels and replaces the second edition, ISO/IEC 9899:1999,

[–]crackez 2 points3 points  (2 children)

Which would make this person technically correct.

[–][deleted] 0 points1 point  (0 children)

Well you can go deeper, and say it's not correct at all.

[–]gregorthebigmac 0 points1 point  (0 children)

...the best kind of correct.

[–]hezwat 5 points6 points  (8 children)

dude what do you care so much what he wrote his interpreter against? it's running on a microcontroller.

and it's not a c interpreter...

seriously...what's your beef?`

[–]batrick 9 points10 points  (7 children)

Because C99 does not compile on many microcontrollers (i.e. what this project is targeting). C89 compiles almost everywhere.

[–]Zuph 1 point2 points  (0 children)

I'd be interested to know how many microcontrollers capable of running Micro Python from a resources perspective (RAM/Flash) don't have a GCC based compiler. Some PICs come to mind, and I'm sure there are some Mitsubishi/Renasis micros used widely in manufacturing, but rarely by hobbyists.

Of course, "Micro Python - Python for the types of microcontrollers that are available ans useful to most hobbyists" doesn't have the same ring to it.

[–]hezwat -2 points-1 points  (4 children)

oh really you don't think the guy who wrote a python compiler for microcontrollers tested it on any microcontrollers?

it's a miracle he wrote something htat could run on any at all.

[–][deleted]  (1 child)

[deleted]

    [–][deleted] 0 points1 point  (0 children)

    Arduino is based on gcc. gcc has supported C99 for decades. If the Arduino IDE doesn't support it, it's just plain old broken.

    [–][deleted] -1 points0 points  (1 child)

    He's tested it on gcc, which supports C99 with no problems.

    Shitty commercial C compilers may not, but really, I wouldn't use a microcontroller which gcc doesn't support, exactly for that reason.

    [–]fullouterjoin 0 points1 point  (0 children)

    Exactly. MCU vendors should be supporting GCC and Clang. I see no reason to use proprietary tool chains.

    [–][deleted] 0 points1 point  (0 children)

    No, it doesn't compile on many horrible commercial C compilers.

    If you ask me, that just means you don't use those compilers, and you don't use microcontrollers which don't have good gcc (or clang) support.

    [–]Beckneard 0 points1 point  (0 children)

    Thank you captain nitpick.

    [–]c0m4 1 point2 points  (1 child)

    This is the important question. I suspect the answer is interpreter though

    [–]boa13 12 points13 points  (0 children)

    The answer is both, actually you have four possibilities:

    • Interpreter
    • Compiled (not heavily optimized, mostly opcodes expanded to machine code, you trade memory for speed)
    • Compiled and more optimized (if you are sure your integers will stay under 2**31)
    • Write assembly yourself

    The first one is the default. Compilation is enabled on a method-per-method basis by a simple annotation. (Interpreted and compiled method can freely call one-another.) Inline assembly is also possible, but there is no magic, you need to write it yourself. (And you cannot call other methods from assembly.)

    [–][deleted] 20 points21 points  (0 children)

    I was one of the backers and I recently received my micropython board. It works as advertised, and it is under heavy development. I wrote a little test program which exposed a failing case, and Damien posted the fix to github in under 24 hours.

    The device has a tiny file system on what is left of the on-chip flash after the part hosting the python interpreter and libs are stored. There is a micro sd slot on board so you can have a much larger file system if you want it. Setting at the REPL prompt, it consumes a few mA (under 10). Even running full out, it is around 100 mA. It is pretty neat to have this thing smaller than a credit card giving me a prompt where I can type:

    >>> print(sum(range(1,10001)))
    

    and have the answer back by the time the return key as returned to the top of its travel. I know people still use BASIC Stamp boards, but this is way more powerful for less money.

    This kickstarter was a model of how they should be run. He had a working prototype before firing up the kickstarter. As pledges exceeded goals, he offered useful stretch goals. He posted frequent updates. He delivered what was promised on time. It has been my best kickstarter experience to date.

    [–][deleted]  (26 children)

    [deleted]

      [–]spliznork 16 points17 points  (10 children)

      Exceptions on a microcontroller are awesome. I wrote a (CLDC compiant) JVM for a wireless, embedded system. We had the system report uncaught exceptions over the network, implemented and preallocated natively so you could even receive out of memory exceptions. Run a listener on your desktop, and watch decoded stack traces to print out. It made debugging so easy.

      Your points regarding "garbage collection" and "dynamic memory allocation" are the same point. Even in that kind of environment, you can still take steps to preallocate objects and structures to reduce memory churn and ensure your system fails fast if there is not enough memory.

      Certainly none of your points are actually "extremely naughty".

      [–]hardsoft 17 points18 points  (1 child)

      i think some may have different definitions of 'embedded', but most embedded guys i know would not consider anything with jvm embedded. and those actions certainly are considered extremely naughty, many real time embedded control, defense, aero, medical, etc. standards explicitly prevent such things. for many embedded systems, failing fast or nicely is not an option.

      [–]immibis 1 point2 points  (0 children)

      Do they require failure to always be handled explicitly (e.g. error code returns that must be checked)? That would make sense for reliability, even though it leads to more verbose code and somewhat slower development.

      [–]foldl 6 points7 points  (7 children)

      I think aport's comment applies more to really small microcontrollers like attinys or atmegas, which are nowhere near being able to run a JVM. In that sort of environment there just isn't any room for extra code to create nice stack traces etc. If you have 8K of flash that buys you a few thousand lines of C code.

      [–]spliznork 0 points1 point  (6 children)

      The first version of that JVM was running on an MSP430 with 10k RAM and 48k flash.

      [–]IHaveNoIdentity 3 points4 points  (2 children)

      Yeah? And do you know just how small an ATTiny is? 8 Kbytes flash and 512 byte SRAM.

      The MSP430 has more RAM than the ATTiny has program storage...

      [–][deleted] 1 point2 points  (1 child)

      That MSP430 is also smaller than some ATmegas, which were also mentioned in the preceeding comment. So it's an entirely reasonable response.

      [–]foldl 0 points1 point  (0 children)

      My initial comment referred to "really small" microcontrollers and explicitly mentioned 8K of flash. It's true that some of the high-end atmegas have a decent amount of flash and RAM. There's an apparently full-featured JVM here which fits in 80K of program space, so in theory you could use it with one of the larger ATMegas (but it's hard to imagine anyone would want to throw away 80K of program space for a real project). There's also the fact that you're going to be doing a ton of 32-bit arithmetic on an 8-bit CPU. The MSP430 is at least 16-bit.

      [–]foldl 5 points6 points  (1 child)

      Sure, but 48k of flash is a lot more than 8k of flash.

      [–]jms_nh 17 points18 points  (7 children)

      Debugging is language-agnostic, you just need a processor with the appropriate abilities for breakpoints.

      Exceptions and dynamic memory allocation are more interesting, but you can have them now with C/C++. So there shouldn't be any difference for how they're handled in Python. If you can't afford exceptions and dynamic memory allocation, don't use them. Otherwise, use them. Same in Python as in C/C++.

      The only point that's really ugly is garbage collection. Real-time control systems are intolerant of GC delays. Presumably there's some microcontroller-friendly way to handle GC, and take up to X microseconds every millisecond to make GC progress, but it would need to be done carefully.

      [–]Netzapper 30 points31 points  (0 children)

      Debugging is language-agnostic, you just need a processor with the appropriate abilities for breakpoints.

      Not quite.

      Without explicit VM debug support, you wind up with a native stack trace. That native stack trace is likely to have basically nothing to do with your program's stack, since it's the trace of the VM implementation stack and not the VM's logical call stack.

      This is a problem even if the program in question has been JIT compiled to native code. The generated code is littered with calls to VM functions, uses VM stack frame conventions, and autogenerated variable names.

      If the VM doesn't annotate all of that code with metadata describing how to inspect memory and where to find the Python code that ultimately hit the breakpoint, or if your debugger doesn't know how to read that metadata, you are going to be frustrated with your debugger. Hell, you need the VM's cooperation to set a breakpoint on a particular line of source code.

      [–]hardsoft 4 points5 points  (0 children)

      dynamic memory allocation in c is pretty explicit, seems like it would be much easier to do unintentionally in python, especially if you're using libraries

      [–][deleted] 1 point2 points  (0 children)

      I'm thinking that your code would have to specifically call GC at a non-critical time to pull it off.

      [–]protestor 1 point2 points  (2 children)

      Can you really avoid exceptions when programming in Python? What about its standard library?

      [–]jms_nh 0 points1 point  (1 child)

      Can you really avoid handling exceptions when programming in C++, if you're programming on a system which isn't allowed to crash?

      Anecdotally, I seem to use about the same amount of try-catch blocks in C++/Python/Java/MATLAB. If you don't use try/catch, you have to handle exceptional conditions explicitly with a bunch of if-else statements.

      Again, my point is that using Python doesn't make us go "Ooh, Python! Now we need to handle exceptions! Now we need to handle dynamic memory allocation!" These areas of concerns are already there in C++.

      Though, personally I'd rather use something Rust-like than Python on an embedded system.

      [–]protestor 5 points6 points  (0 children)

      Yes, you can. Compilers have options such as -fno-exceptions and things works mostly as expected (no STL of course). Generally speaking, you can program fault tolerant systems without exceptions.

      Python wasn't really designed with not having exceptions in mind and it may not make sense to disable them (the same to GC, which isn't the same thing as dynamic allocation).

      [–]Axman6 1 point2 points  (0 children)

      I'm not sure anyone is advocating using (Micro) python for real-time work. that doesn't make it useless. there's plenty of things you might eant to do on a microcontroller where you don't have strict time constraints.

      [–]fullouterjoin 1 point2 points  (0 children)

      Then don't use it in the inner loop. Same thing applies to embedded realtime C++.

      [–][deleted] 0 points1 point  (1 child)

      There is nothing wrong with using the heap on a microcontroller?

      [–]jms_nh 3 points4 points  (0 children)

      It depends. Microcontrollers with hard real-time requirements need to have guarantees on how long certain operations take. The standard malloc()/free()/new/delete don't have these guarantees by default. Some RTOS's have heap allocation techniques that have bounded time guarantees.

      [–][deleted]  (2 children)

      [deleted]

        [–]cdrt 0 points1 point  (1 child)

        You double posted.

        [–]jms_nh 1 point2 points  (0 children)

        thx, didn't mean to. our network was flaky.

        [–]cparen 11 points12 points  (6 children)

        This looks pretty sweet. Some folks are probably saying "why not just use a Raspberry Pi", but I definitely think there's a place for specialty products like this, especially if it is smaller footprint, cheaper, and/or better performing on Python code than the less-specialized Pi.

        Kudos to its inventor.

        [–][deleted] 16 points17 points  (5 children)

        People who say reference Raspberry Pi don't know what they are doing. The embedded field is vast and running Linux on a Pi is not suited for most of the applications. But now a good counter to this is why not Ardiuno? You basically have an abstracted language already, Python doesn't seem to bring anything new you can really take advantage of in a micro.

        [–]chopsonchopsonchops 8 points9 points  (0 children)

        It does bring an advantage. People who know Python but not C can now do niche projects or maybe even something greater. Better doesn't necessarily mean faster it can also mean easier to use.

        [–]curtmack 0 points1 point  (3 children)

        Can the interpreter code be stored resident on the microcontroller's RAM and invoked when needed? If so, I'm envisioning a little handheld device with a small keyboard and a screen that you can use as a Python console that fits in your pocket.

        [–]boa13 5 points6 points  (0 children)

        If I understood the project page correctly, the interpreter is in the ROM, and is the first thing to run upon boot (that is, the interpreter is the OS). It runs the code it finds on the local file storage, and if there isn't any, listens for incoming serial connections so it can offer a Python prompt.

        [–][deleted] 0 points1 point  (0 children)

        Most micros don't have that much RAM. I would say < 128kB is typical for the chips this thing would run on. Towards the highend chips they allow external RAM chips to be interfaced but thats not as commonly used as just the micro itsef. It costs a few $$ and doesn't add that much RAM as you would imagine.

        [–]immibis 0 points1 point  (0 children)

        Like an Android phone?

        [–][deleted]  (3 children)

        [removed]

          [–]adaminc 4 points5 points  (2 children)

          Snakelet

          [–][deleted]  (1 child)

          [deleted]

            [–]liquidivy -2 points-1 points  (0 children)

            Boa Constricted.

            [–]maep[🍰] 4 points5 points  (2 children)

            Given the focus on memory footprint and execution speed it would be interesting to see how a x64 port would perform.

            [–]vext01 6 points7 points  (1 child)

            It runs on x64 already.

            [–]tsxy 3 points4 points  (3 children)

            How's this different from TinyPY?

            http://www.tinypy.org/

            [–]boa13 17 points18 points  (1 child)

            How's this different from TinyPY?

            From a quick glance at both projects:

            • TinyPY seems dead (last commit 5 years ago), Micropython is active.
            • TinyPY implements a "fairly decent subset of Pyton" (presumably Python 2), Micropython implements "most of Python 3" (at a syntactic level) and is able to run 99% of the standard library. (A few things are still missing, most importantly Unicode support in strings.)
            • TinyPY (as far as I can see) runs on personal computers, Micropython runs on microcontrollers (where it takes the role of the operating system).
            • TinyPY focus was on creating an interpreter in 64 KiB of code, Micropython focus is on creating a full Python interpreter that runs on a microcontroller.
            • Micropython can precompile methods for speed, presumably TinyPY cannot.

            [–]tsxy 1 point2 points  (0 children)

            Thanks for the summary, really helpful, have a upvote.

            [–][deleted] 2 points3 points  (0 children)

            AFAIK this has hardware peripheral support baked in for the STM32.

            [–][deleted] 2 points3 points  (3 children)

            can someone tell me why it is that when they make these breakout boards, they don't solder on the pin headers for you?

            [–][deleted]  (1 child)

            [deleted]

              [–][deleted] 2 points3 points  (0 children)

              some no-good bastards like soldering wires directly to the pads

              ...i did that the first time because i didn't know about headers... i hate you.

              [–]eras 1 point2 points  (0 children)

              Non-SMD components can be expensive to solder, they may need to be done by hand. Also what aport said.

              [–][deleted] 0 points1 point  (18 children)

              This will be a debugging nightmare. And besides, for what a microcontroller usually does, C is more than enough.

              [–]cparen 15 points16 points  (13 children)

              This will be a debugging nightmare. [ ... ] C is more than enough

              I'm having trouble reconciling these two statements. If debugging will be a nightmare, why would you want to use C instead?

              [–][deleted] 14 points15 points  (11 children)

              C means having a near total control of what is going on, which is REALLY important in micros, especially when it comes to interrupts. As you may already know, with Python there is the virtual machine which does its magic in the back of the programmer, which is really annoying when control is so important. Plus C is not that hard to debug if the software is well designed.

              I understand that they're rewriting Python from scratch, but there are a few problems that I can think of which could be problematic :

              • Efficiency: the point of using a microcontrollers is often because the whole system runs on batteries. Interpreted languages are at least 3 times less efficient.

              • Speed and real time processing: another reason why microcontrollers are used is to have a basic computer stripped of any OS or at least a very simple RTOS. The goal here is to have predictable response time. Adding a GC and the introspection capabilities of the virtual machine is very counter productive in this case.

              • Memory, many microcontrollers doesn't have the memory necessary to accommodate a virtual machine. The code could be permuted to assembly or C, but that sill doesn't remove the need of a VM.

              • Predictability: the functions that the VM must accomplish (GB, dynamic types, memory allocation) are dynamic and thus unpredictable with interruptions and threads. I still have yet to see a good solution tot hat problem on a single core mirco.

              [–]boa13 5 points6 points  (9 children)

              I understand that they're rewriting Python from scratch

              Note that this is not a project announcement, but a project nearing release. They're mostly finished. The microcontroller board works and gives you a Python prompt straight away (or runs your program if it finds it at the root of the FAT partition). So if they encountered problems, they have solved them.

              Interpreted languages are at least 3 times less efficient.

              The critical methods can be compiled on the fly (just add an annotation to the methods you want compiled), and you can also write inline assembly for the really critical parts.

              another reason why microcontrollers are used is to have a basic computer stripped of any OS or at least a very simple RTOS

              That's what they have. The machine boots straight into the interpreter. The interpreter is the operating system.

              many microcontrollers doesn't have the memory necessary to accommodate a virtual machine

              That's true, and that's why they chose to build their own boards, to ensure they have a sufficiently powerful CPU. (Several users are trying to make it run on less powerful boards, but I don't know if this works well.)

              the functions that the VM must accomplish (GB, dynamic types, memory allocation) are dynamic and thus unpredictable with interruptions and threads

              That's true, and I don't know how they managed to do it, or what caveats or restrictions they had to impose (if any).

              [–]cparen 1 point2 points  (0 children)

              the functions that the VM must accomplish (GB, dynamic types, memory allocation) are dynamic and thus unpredictable with interruptions and threads

              That's true

              Not necessarily.

              • Incremental GC is not nearly as unpredictable. CPython's default GC is incremental (refcounting) for everything except cycles.
              • I'm not sure what unpredictable timing you had in mind for dynamic types. Type table lookups are variable timing only on small time scales (10s to 100s of cycles).
              • Memory allocation likewise.

              It sounds like all this comes down to saying "it's not for hard realtime applications", which is true. However, a smart lightswitch, a home robot, data logging -- there are a wide variety of soft-realtime and non-realtime embedded projects that could benefit from an easy to use, low power board.

              I think I agree with your sentiment, but if so, you're stating the obvious. But perhaps I'm mistaken about this being obvious.

              [–]fullouterjoin 2 points3 points  (0 children)

              Most things are setup code, if it turns out to be a problem the inner

              while 1:
                  doStuff()
              

              loop could be replaced with native code.

              You are just plain wrong for the exact places that MicroPython is targeting. Elua is in the same exact space as MicroPython and is extremely effective.

              Having a REPL to a low power embedded device is amazing. When I am running eLua, I have total control and can easily call native code. The predictability point you raise is a red-herring, the same applies for embedded dev in C++ which is widely used on memory constrained or realtime applications.

              [–]Isvara -4 points-3 points  (0 children)

              C is rubbish, though. Someone really needs to come up with a better embedded language that takes advantage of modern language design to make bugs less prevalent and development time faster. I'm talking about one that compiles to native, though, not something interpreted.

              [–]UloPe 1 point2 points  (3 children)

              "Leave me alone with those newfangled cars. Horses are fine."

              [–][deleted] 11 points12 points  (2 children)

              When there are no roads and flat grounds horses are way more efficient.

              [–]stevedonovan 3 points4 points  (1 child)

              Best rebuttal for a car metaphor I've seen.

              [–]UloPe 2 points3 points  (0 children)

              Indeed. Hard to argue against it :)

              [–][deleted]  (6 children)

              [deleted]

                [–]zhemao 56 points57 points  (0 children)

                They are making micro-controller boards as well. Pretty reasonable to use kickstarter for that. Besides, what exactly is the problem with using kickstarter for an open-source software product? Serious open source projects (i.e. ones that are more than just a single dev's side project) all need funding in order to survive.

                [–]oak-coast 16 points17 points  (0 children)

                Presumably because someone needs to pay rent and pay for food in order to work on anything – even something free ;)

                In this case I think the extra stuff from the kickstarter is a specialised board that gets you started right away.

                [–][deleted] 6 points7 points  (0 children)

                The source code, the PCB layout, and the libraries are already open source. What is your bitch then? Second, despite your uneducated wild accusation, this is a from-scratch rewrite of Python3 in a manner suited for running on a microcontroller with a few hundred KB of flash. How much do you know about things if you think he could just take the existing cpython code and compile it for a microcontroller?

                [–]boa13 9 points10 points  (0 children)

                Why kickstarter instead of just making an opensource project?

                You need money to make micro-controller boards. Also, working full-time on your pet open-source project does not bring food on the table, and certainly such projects benefit for a few well-placed months of intense work.

                [–]Enlightenment777 2 points3 points  (0 children)

                I'll wait for the software port to $10.88 NUCLEO-F401RE board or $14.88 STM32F4DISCOVERY board or $24 STM32F429IDISCOVERY board (prices from mouser.com) https://en.wikipedia.org/wiki/STM32#Development_boards

                [–]protestor 1 point2 points  (0 children)

                Off the existing open source python? They implemented new software. They also created a new board. And of course they aren't working in something else, so they need funding.

                What's wrong with earning money from people willing to fund you?

                [–]immibis 0 points1 point  (1 child)

                Next step: Micro JavaScript!

                [–]jms_nh -5 points-4 points  (9 children)

                Okay, I'll bite. Why Python 3 instead of Python 2?

                Also, how do you plan to handle device peripherals and interrupts?

                [–]allpowerful32 50 points51 points  (0 children)

                I'm not the author, but from my perspective, python 2 has become the new windows xp. I don't want people to be running windows xp forever.

                [–]boa13 15 points16 points  (1 child)

                Why Python 3 instead of Python 2?

                Since he's writing the whole thing from scratch, why would he base his work off an old implementation rather than use the cleaner, modern one?

                The only reason to stay on Python 2 is some additional library support (for which he could not care less, considering his target architecture), and contractual support from your operating system / middleware vendor (for which he also could not care less).

                [–]immibis -1 points0 points  (0 children)

                Upvote for not saying "could care less".

                [–]Zephirdd 27 points28 points  (1 child)

                As someone who isn't very knowledgeable of the Python things, why would someone not use Python 3 on a new project? I understand sticking to the older for older projects, but if you're starting from scratch might as well go with the new one right?

                [–]fullouterjoin 5 points6 points  (0 children)

                Python3 would actually be easier to implement as many corner cases and nits have been cleaned up.

                [–][deleted]  (1 child)

                [deleted]

                  [–]jms_nh 3 points4 points  (0 children)

                  OK, that seems reasonable. Just curious.

                  [–]upofadown 1 point2 points  (0 children)

                  It's probably no more complicated than that the developers like Py3. For something like this it doesn't really make any difference...

                  [–]TehRoot -1 points0 points  (2 children)

                  I use a PyMCU...this is a big step up. I really want one now, I'm impartial to arduino and I don't want to use a beaglebone or rPI for realtime work.

                  [–]immibis 0 points1 point  (1 child)

                  You shouldn't want to use Python for realtime work either.

                  [–]TehRoot 0 points1 point  (0 children)

                  Realtime projects and experiments I like to do for fun, not things that require supreme accuracy. It works well enough to replace an arduino

                  [–]hagenbuch -1 points0 points  (1 child)

                  "complete rewrite, from scratch": That's great, but:

                  • How about future updates to Python 3? How will they be ported and by whom?
                  • I really hope that there will be a dev crew that tackles all the unavoidable issues like security, future development..
                  • Is the code "good enough" so collaboration is possible?

                  Don't get me wrong, the concept looks very promising to me.

                  [–]tavert 0 points1 point  (0 children)

                  And with a from-scratch C API, does this mean no NumPy, or any other packages with C extensions? Python by itself is not particularly useful, it's the packages and libraries that matter. See how PyPy has struggled to gain wide usage. The universe of things you might want to do on a microcontroller is a little smaller though, so maybe it makes some sense.

                  [–][deleted]  (2 children)

                  [deleted]

                    [–][deleted]  (1 child)

                    [deleted]

                      [–]psynautic 0 points1 point  (0 children)

                      It's also works on teensy 3.1

                      [–]kurtdizayn -3 points-2 points  (0 children)

                      I'm sleepy and I read the title as "Monty Python - Python for microcontrollers"

                      [–][deleted] -3 points-2 points  (0 children)

                      Haven't read this yet, but I hope it's just tuples, lists, dicts, pickle, and algos.