If we can't actually use Python to use a Propeller and do awesome things, then it's never, ever, ever going to be worth it to learn about Python on the Propeller.
I agree, which is why I actually examined some details of common control-flow that could be ported to the Prop in #173
Those control-flow examples and links, are within the realms of existing Prop compiler technology.
The resulting code should have speed very similar to Prop Basic. (and similar ceilings)
It seems other MCUs are supporting Python, in various subset forms, which may be why Ken was asking.
(and yes, any MCU support, of any language, is always going to be a subset, just as the resource itself is a subset )
It seems other MCUs are supporting Python, in various subset forms, which may be why Ken was asking.
(and yes, any MCU support, of any language, is always going to be a subset, just as the resource itself is a subset )
Which other MCUs? They're all ARMs aren't they? That's a completely different class of processor than one constrained to 32k of code+data space.
And something like this is not all technical. It is, in that some things are possible, and the nature of those things depends on the tech investment made. Prop gcc is a good case in point.
There is also a basic value judgement, and on that basis, barring some real tech so far not discussed, Python fails.
Just because it can be done, doesn't mean it should. A limited thing could doore harm than good. People may well ask, "why?" Could go bad from there
It seems to me that if you take dynamic typing and dynamic memory management out of Python then you end up with too small a subset to be used in the way Python is usually used. And those are part of what makes Python impractical on a P1 or an ATmega328 or other small MCUs.
.
I'm not really following this, as the MCU resource is what controls what can be managed, not what might be done on a PC.
MCU development is always going to be different from "the way XYZ_Language is usually used", no matter what language is chosen.
Also, if you take interactivity away then you also take away one of its useful features for beginners. If you end up with a language that has to be compiled on a PC and downloaded to the Propeller, you may as well just use C or Spin or PropBasic.
I'm not following the first part, unless you are advocating full self hosting, (for which a Prop is hopelessly under-resourced), then any language is going to be "compiled on a PC and downloaded to the Propeller"
That surely is part of what student need to learn, as they learn MCUs, that their code does does not run on the PC.
Once someone moves onto MCU, they are not really a beginner, but there are merits in being able to use what they have learned already, for testing and algorithm porting.
Re those alternatives :
Can those beginners run up their Spin Code in a Full PC environment, and check algorithms ?
Likewise with PropBasic - which PC hosted Basic* is close enough to PropBasic, to allow algorithm development testing and porting ?
Looks like that leaves C, and if C already does all this, why are so many schools moving to teach python instead ?
* I have advocated before making PropBASIC more like available PC Basics, to cover exactly the "learning-flow" issues discussed here, as that seemed to be the least effort.
However, compilers like PropBASIC can also be modified to take the control-flow syntax of Python, and compile that instead.
Compilers do not have to lose interactivity, but it does take more work as you need good debug support.
That was what launched the original Turbo Pascal - the Editor/Debug/Compiler made it interactive.
Does a teacher care which core is being used ?
That resource difference is what points to a compiler solution for the Prop.
I see no value in something that looks sort of like Python but has few if any of the features that make Python powerful and easy to use. By the way, I'm pretty sure you could get a largish subset of Python working on a Propeller if you were willing to add a SPI flash chip and maybe some SPI SRAM chips. You can certainly do it if you add something like jazzed's 32MB SRAM board. However, the performance will probably be terrible.
By the way, I'm pretty sure you could get a largish subset of Python working on a Propeller if you were willing to add a SPI flash chip and maybe some SPI SRAM chips. You can certainly do it if you add something like jazzed's 32MB SRAM board. However, the performance will probably be terrible.
Notice how that "a largish subset " has resulted in "performance will probably be terrible".
Hence the suggestion for a control-flow subset that can compile to a Prop (no extra chips), and give performance the same as other compiled languages.
The print statements in Python look very similar to those already in xBasic/PropBasic, so that level of interactive remains.
Could you take xBasic and modify to swallow the control-flow lines in #173 ?
Could you take xBasic and modify to swallow the control-flow lines in #173 ?
Yes but I doubt would ever get used. If Parallax wants that, I'd be happy to do it for them though. I'd like to hear from Ken again in this topic. He brought up the subject so it would be interesting to hear what he thinks a useful subset would be.
I am a programmer. I do this for a living since decades. I had other jobs in my life, before and in between, but it boils down to: I am a programmer.
The first language I learned was BASIC on a WANG 2000. Then assembly on TRS80 and IBM/350/360/370. Then COBOL, FORTRAN and ALGOL. All of my life I had to learn new languages, concepts and coding rules forced on me by different employers or projects. Do I care about yet another language? Not at all.
You do not learn programming by learning a language. You have to learn and acquire a mindset. How to get a real world problem solved with the help of a computer.
Problem solving and analytic thinking, System Analysis and integrating stuff into the workflow of a company, Mainframe Environment compared to PC or the Cloud services now in the internet. You have to handle all of this. The idea you learn C /C++ and all is done is just ridiculous.
To sort out those who are programmers from the other ones is not at all language dependent. Either they get the abstraction or they don't.
It is a illusion to think everybody will be able to write computer programs. And there is no need for either. Being able to read and write Greek, Latin, French. Russian, English or German does not make you a great philosopher or author of great novels.
All of them language (and OS) wars are as useful as comparing sizes in the locker room. It is just not helpful at all and does not really matter anyways.
Being a programmer implies - IMHO - your ability to adopt to any language, OS and Environment (as of company goals, hardware, coding styles, etc.)
If you don't - well you aren't one.
Sorry to pick you two, but this is just an example.
I am sure that after a two weeks serious training (from me :smile) @Heater would be able to program COBOL without a problem and @Potatohead could do code reviews. No joke here.
@Heater and @Potatohead are just randomly picked, we have a good crowd of programmers around here.
Short:
The language does not matter at all for education. The subject to teach needs to understand the abstraction needed to solve the problem.
Nothing wrong with Modula2, Lisp and whatever other language you like.
I've already given a breakdown in #173, strange how so many work on reflex feelings and cannot focus on technical details ?
Are you suggesting I am not at least trying to apply some logic to this topic?
I asked what Python language features one would be prepared to remove in order to try and get a Python run time to fit in the Propeller. Your post #173 kicks off with talking about conditional support which is not a Python feature and then pastes some Python source that indicates that syntactically there are lot of things that look like they are easily compilable to something the Prop can run, like: var, if/elif/else, while, for/in, dictionary...
So far so good, it does not answer my question though.
Off the top of my head here is a list of Python language features:
• dynamic types
• Mixed type in arrays
• lists/slices
• tuples
• size of numbers (ints can be huge)
• string concatenation
• memory management/garbage collection
• lambdas
• generators
• exceptions
• import - modules
• exec
• assertions
• classes
• higher order functions
• A ton of built in functions I won't list here.
I'm no Python expert so excuse any errors in terminology and I'm sure there are things missing.
You are right, my "reflex feelings" at this point are that it looks like pretty much any one of those features would start to make for a rather large run time and many of them would have to be dropped from the proposed Python subset for the Propeller. At which point the resulting language is nothing like Python, can not be used like Python and does not meet the requests for Python on the Propeller.
Those are the "brick-walls" I see.
Quite frankly, warning - more "reflex feeling" coming, if those educators don't want to be teaching the nuts and bolts of bits and bytes, real-time issues, assembler and other low level computing/embedded system details then they should just stock up on MicroPython boards or Raspberry Pi's and float off into the land of abstraction. I'm starting to feel very sorry for their students.
At which point the resulting language is nothing like Python, can not be used like Python and does not meet the requests for Python on the Propeller.
Again, the claims 'nothing like python' and yet it is a cut-and-pastable subset, from a python test module.
As for 'does not meet the requests' - can you point to the list of 'must have' features from Ken, or someone who is actually asking ?
A small MCU target is always going to impose constraints, so I approach the problem from below, and look for what can be done, rather than from above.
...the claims 'nothing like python' and yet it is a cut-and-pastable subset, from a python test module.
Yes indeed. My 'nothing like python' ranges from 'quite a lot like Python' to 'nothing like python, why bother?' depending on how many of the Python language features I listed are missing. And no doubt a bunch of others I have missed out.
I'm not sure what you mean by this cut and paste business. One could imagine creating a language that compiles reams of selected C code and yet is a language nothing like C, does not have features that the selected code does not exercise and would be roundly rejected as a C implementation. Heck I can cut and paste C code into JavaScript and have it run.
...can you point to the list of 'must have' features from Ken, or someone who is actually asking ?
Of course not. I'm betting that if one asked the question of someone making such a request they would have no idea themselves. They would just say "we want Python".
A small MCU target is always going to impose constraints, so I approach the problem from below, and look for what can be done, rather than from above.
A good approach.
My only claim is that creating a "not Python" language that is only superficially, syntactically, looking like Python to some extent is not the way to go. It's redundant as we have a ton of languages that work just as well or better on the Prop already. It's a confusion for any students as it looks like Python but is not. And it does not meet the request for "Python on the Propeller".
Ultimately the only way to resolve this is to build such a "Not Python" and see how well it flies. We look forward to seeing what you come up with.
Ultimately the only way to resolve this is to build such a "Not Python" and see how well it flies. We look forward to seeing what you come up with.
The decision is down to the company fielding the requests & I'm not the one fielding the requests, but I did notice David Betz to Ken said it was possible in #190.
Ken may even choose to call it something else, as your main reflex seems to be 'not python', even tho quite plainly a MCU is 'not a PC' either...
Control-Flow MCU Python would not confuse me, and underlines that a MCU is not a PC.
It's redundant as we have a ton of languages that work just as well or better on the Prop already.
Yet strangely, Parallax are getting increasing requests for Python ? Hence this thread and the title itself.
Seems that "a ton of languages that work just as well or better on the Prop already" claim, is not resonating out there ?
Stepping back a little from the original question, given Parallax also need a successor to BS-2, they could instead grab a 2015 large 'MCU', (eg 2MBF.512KR, 200MHz) which can run MicroPython, and present that to their customer base, solving two problems at once.
The decision is down to the company fielding the requests & I'm not the one fielding the requests, but I did notice David Betz to Ken said it was possible in #190.
Yes, a "not python" language could be created. In fact, I've already started work on a "notc" language. However, I have no hopes of it being actually used. I am just working on it to see how complete an interactive C-like language I can fit on a Propeller. I really think that if Parallax were to offer a "not quite python" language, they would generate a huge customer support problem answer questions about why this or that feature is missing. In the end, it might be easier to just steer those people to Spin or C++.
Ken may even choose to call it something else, as your main reflex seems to be 'not python', even tho quite plainly a MCU is 'not a PC' either...
Control-Flow MCU Python would not confuse me, and underlines that a MCU is not a PC.
Of course this could be done. A PC-based compiler could probably be written to target the Spin VM. Whether it has value is another question. Only Ken knows what his customers are requesting and he hasn't posted a list of requirements. One big question is if the language should be interactive or if it can use a PC-based compiler.
Yet strangely, Parallax are getting increasing requests for Python ? Hence this thread and the title itself.
Seems that "a ton of languages that work just as well or better on the Prop already" claim, is not resonating out there ?
Stepping back a little from the original question, given Parallax also need a successor to BS-2, they could instead grab a 2015 large 'MCU', (eg 2MBF.512KR, 200MHz) which can run MicroPython, and present that to their customer base, solving two problems at once.
I think this is a good idea but I doubt it will ever fly. It seems like Parallax could take their considerable expertise in creating educational material and apply it to a board built around someone else's MCU. This is, of course, what they have already done with the BASIC Stamp. However, it seems that now any new educational offering must be based on the Propeller. A compromise might be to build a board with both an ARM and a Propeller and a version of Python that is tightly integrated with the Propeller as an I/O accessory but that has been suggested many times without any success.
.... One big question is if the language should be interactive or if it can use a PC-based compiler.
True, but with care, I think it can be both - it does not need 'or' .
Interactive is what any good remote-debugger offers, and compile and download times should be tolerably fast.
Certainly a PC_based compiler slashes the resource load on the MCU, and boosts performance.
A compromise might be to build a board with both an ARM and a Propeller and a version of Python that is tightly integrated with the Propeller as an I/O accessory but that has been suggested many times without any success.
Yes, a good idea, but I suspect the P2 is a distraction, as they hope more will fit into that.
A small-steps solution to your approach, would be a RaspPi slave board, that has the "version of Python that is tightly integrated with the Propeller as an I/O accessory" as part of the package.
The choice of which larger-ARM-MCU as a host is widening all the time - I see Spansion mention Graphics engines and HyperFLASH/HyperRAM interfaces in their next generation Automotice console 'MCUs', sampling soon.
That breaks the "few-MB" ceiling of even the larger MCUs, but keeps the pin-counts manageable.
A small-steps solution to your approach, would be a RaspPi slave board, that has the "version of Python that is tightly integrated with the Propeller as an I/O accessory" as part of the package.
I think Bill Henning already offers this solution.
True, but with care, I think it can be both - it does not need 'or' .
Interactive is what any good remote-debugger offers, and compile and download times should be tolerably fast.
Certainly a PC_based compiler slashes the resource load on the MCU, and boosts performance.
This is true and could be a good solution although it won't be interactive in the same way that "real" Python is interactive.
This is true and could be a good solution although it won't be interactive in the same way that "real" Python is interactive.
Sure, but any MCU development loop, is never quite as interactive as a Native-PC loop.
Modern serial links can help slash the download times to most MCUs, tho the present Prop boot design needs some help ...
Sure, but any MCU development loop, is never quite as interactive as a Native-PC loop.
Modern serial links can help slash the download times to most MCUs, tho the present Prop boot design needs some help ...
Not true if you're using an MCU that can fully host the language in question. For example, an ARM with sufficient flash and SRAM can host an interactive version of Python and even a Propeller can host Tachyon Forth which is interactive.
If you're forced to use a powerful SOC ARM you as well go with Embedded Artists LPC4088 board, it has 32MB of SDRAM and 8 MB of flash in a 44 pin DIP package. It may be just enough to handle the bloat of Python.
The micropython port to the esp8266 WiFi modules is making progress.
WiFi is said to be at least kind of running but the esp8266 specific gpios are not supported yet...
Optimistic view: Within some weeks :-) or months :-( we'll have a $3 python coprocessor with WiFi abilities for the propeller...
The micropython port to the esp8266 WiFi modules is making progress.
WiFi is said to be at least kind of running but the esp8266 specific gpios are not supported yet...
Optimistic view: Within some weeks :-) or months :-( we'll have a $3 python coprocessor with WiFi abilities for the propeller...
Sure, but any MCU development loop, is never quite as interactive as a Native-PC loop.
Modern serial links can help slash the download times to most MCUs, tho the present Prop boot design needs some help ...
Interesting, I'll need to check for that compile/download step when I'm using espruino, micropython, forth or micromite basic on various micros even Propforth or Tachyon on Propellers. It must be a REALLY short part of the development loop!
David has the chops to make a language with a Python like syntax. Skills of which I am envious. He also says he would not expect anyone to use it. I guess for the same reason people don't use a million other such experimental languages. Besides it's not what the customer ordered as far as I can tell. Ken would have to set us straight on that.
I'm not following the idea behind "an MCU is not a PC". That is clearly true. It's all a fuzzy distinction though. A modern MCU is faster and has more memory that the PC's we were using not long ago. JavaScript, Python, Lua and such are a reality on tiny, amazingly cheap micro-controllers. Who would want this "Control-Flow MCU Python"? What would they do with it?
...strangely, Parallax are getting increasing requests for Python ?...Seems that "a ton of languages that work just as well or better on the Prop already" claim, is not resonating out there ?
Apparently you are right. I cannot account for it. My conclusion is these guys don't want to teach the binary and hex and assembler and real-time concerns of the low level of the embedded or even "normal" computing world. But they want to use a tiny MCU. They are very confused:)
...they could instead grab a 2015 large 'MCU', (eg 2MBF.512KR, 200MHz) which can run MicroPython, and present that to their customer base, solving two problems at once.
They could...I suspect Chip would have something to say about that.
A small-steps solution to your approach, would be a RaspPi slave board, that has the "version of Python that is tightly integrated with the Propeller as an I/O accessory" as part of the package.
Yes. I'm totally with you there. An idea I and others suggested the minute the Pi came out. Such a huge potential market and all neatly aligning with the educational activities of Parallax and the Raspberry Pi Foundation.
No special version of Python required for that. Perhaps a Propeller board interfacing library, and all the C and Spin tools for the Pi supported properly.
@David,
I think Bill Henning already offers this solution.
Yep. Bill has been doing sterling work in that direction.
...any MCU development loop, is never quite as interactive as a Native-PC loop
Have you tried playing with JavaScript on STM32 F4? Exactly the same interactive as the node.js or many other REPLs on a PC. I have no idea if MicroPython does that but I suspect it does.
Don't let the Forth guys hear you say that
@yeti,
Within some weeks :-) or months :-( we'll have a $3 python coprocessor with WiFi abilities for the propeller...
I guess that is the way to get Python on the Prop. Use the Prop to make a terminal to a Python engine on your WIFI adater. Neat:)
@David,
Isn't that like the tail wagging the dog?
Could be. Around here just now is a thread going on about using an esp8266 WIFI adapter with the Propeller. Last I looked at that thread they seem to have come to the realization they can do what they want in Lua on the esp8266 and don't need the Propeller !
Not true if you're using an MCU that can fully host the language in question. For example, an ARM with sufficient flash and SRAM can host an interactive version of Python and even a Propeller can host Tachyon Forth which is interactive.
Weeeelll, that's rather a stretch, as I include proper source editing in the development loop.
Command line 'interactive' is not quite the interactive modern student expect.
They certainly expect a syntax highlighting editor, that has other smarts like find declaration.
I guess that is the way to get Python on the Prop. Use the Prop to make a terminal to a Python engine on your WIFI adater. Neat:)
That's what OBC's MicroMite Companion board is all about. It uses the Propeller as a terminal to talk to a PIC32 that is running a Basic interpreter. You could use the same idea with an MCU that can run Python. Of course, since you're likely to have COGs left over after running a VGA video driver and keyboard COG, you can use those to provide I/O capability to the Basic or Python or whatever program is running on the PIC32 or ARM. I wonder if the PIC32 chip that OBC uses has enough flash/SRAM to run Python? Maybe his board could be used to make a "Python Companion".
Comments
I agree, which is why I actually examined some details of common control-flow that could be ported to the Prop in #173
Those control-flow examples and links, are within the realms of existing Prop compiler technology.
The resulting code should have speed very similar to Prop Basic. (and similar ceilings)
It seems other MCUs are supporting Python, in various subset forms, which may be why Ken was asking.
(and yes, any MCU support, of any language, is always going to be a subset, just as the resource itself is a subset )
There is also a basic value judgement, and on that basis, barring some real tech so far not discussed, Python fails.
Just because it can be done, doesn't mean it should. A limited thing could doore harm than good. People may well ask, "why?" Could go bad from there
MCU development is always going to be different from "the way XYZ_Language is usually used", no matter what language is chosen.
I'm not following the first part, unless you are advocating full self hosting, (for which a Prop is hopelessly under-resourced), then any language is going to be "compiled on a PC and downloaded to the Propeller"
That surely is part of what student need to learn, as they learn MCUs, that their code does does not run on the PC.
Once someone moves onto MCU, they are not really a beginner, but there are merits in being able to use what they have learned already, for testing and algorithm porting.
Re those alternatives :
Can those beginners run up their Spin Code in a Full PC environment, and check algorithms ?
Likewise with PropBasic - which PC hosted Basic* is close enough to PropBasic, to allow algorithm development testing and porting ?
Looks like that leaves C, and if C already does all this, why are so many schools moving to teach python instead ?
* I have advocated before making PropBASIC more like available PC Basics, to cover exactly the "learning-flow" issues discussed here, as that seemed to be the least effort.
However, compilers like PropBASIC can also be modified to take the control-flow syntax of Python, and compile that instead.
Compilers do not have to lose interactivity, but it does take more work as you need good debug support.
That was what launched the original Turbo Pascal - the Editor/Debug/Compiler made it interactive.
That resource difference is what points to a compiler solution for the Prop.
Notice how that "a largish subset " has resulted in "performance will probably be terrible".
Hence the suggestion for a control-flow subset that can compile to a Prop (no extra chips), and give performance the same as other compiled languages.
The print statements in Python look very similar to those already in xBasic/PropBasic, so that level of interactive remains.
Could you take xBasic and modify to swallow the control-flow lines in #173 ?
The first language I learned was BASIC on a WANG 2000. Then assembly on TRS80 and IBM/350/360/370. Then COBOL, FORTRAN and ALGOL. All of my life I had to learn new languages, concepts and coding rules forced on me by different employers or projects. Do I care about yet another language? Not at all.
You do not learn programming by learning a language. You have to learn and acquire a mindset. How to get a real world problem solved with the help of a computer.
Problem solving and analytic thinking, System Analysis and integrating stuff into the workflow of a company, Mainframe Environment compared to PC or the Cloud services now in the internet. You have to handle all of this. The idea you learn C /C++ and all is done is just ridiculous.
To sort out those who are programmers from the other ones is not at all language dependent. Either they get the abstraction or they don't.
It is a illusion to think everybody will be able to write computer programs. And there is no need for either. Being able to read and write Greek, Latin, French. Russian, English or German does not make you a great philosopher or author of great novels.
All of them language (and OS) wars are as useful as comparing sizes in the locker room. It is just not helpful at all and does not really matter anyways.
Being a programmer implies - IMHO - your ability to adopt to any language, OS and Environment (as of company goals, hardware, coding styles, etc.)
If you don't - well you aren't one.
Sorry to pick you two, but this is just an example.
I am sure that after a two weeks serious training (from me :smile) @Heater would be able to program COBOL without a problem and @Potatohead could do code reviews. No joke here.
@Heater and @Potatohead are just randomly picked, we have a good crowd of programmers around here.
Short:
The language does not matter at all for education. The subject to teach needs to understand the abstraction needed to solve the problem.
Nothing wrong with Modula2, Lisp and whatever other language you like.
It is the mindset you need to learn.
Mike
I asked what Python language features one would be prepared to remove in order to try and get a Python run time to fit in the Propeller. Your post #173 kicks off with talking about conditional support which is not a Python feature and then pastes some Python source that indicates that syntactically there are lot of things that look like they are easily compilable to something the Prop can run, like: var, if/elif/else, while, for/in, dictionary...
So far so good, it does not answer my question though.
Off the top of my head here is a list of Python language features:
• dynamic types
• Mixed type in arrays
• lists/slices
• tuples
• size of numbers (ints can be huge)
• string concatenation
• memory management/garbage collection
• lambdas
• generators
• exceptions
• import - modules
• exec
• assertions
• classes
• higher order functions
• A ton of built in functions I won't list here.
I'm no Python expert so excuse any errors in terminology and I'm sure there are things missing.
You are right, my "reflex feelings" at this point are that it looks like pretty much any one of those features would start to make for a rather large run time and many of them would have to be dropped from the proposed Python subset for the Propeller. At which point the resulting language is nothing like Python, can not be used like Python and does not meet the requests for Python on the Propeller.
Those are the "brick-walls" I see.
Quite frankly, warning - more "reflex feeling" coming, if those educators don't want to be teaching the nuts and bolts of bits and bytes, real-time issues, assembler and other low level computing/embedded system details then they should just stock up on MicroPython boards or Raspberry Pi's and float off into the land of abstraction. I'm starting to feel very sorry for their students.
I don't mind bring picked on. No worries.
Edit: Heater too. Didn't see it prior to this one.
As for 'does not meet the requests' - can you point to the list of 'must have' features from Ken, or someone who is actually asking ?
A small MCU target is always going to impose constraints, so I approach the problem from below, and look for what can be done, rather than from above.
I'm not sure what you mean by this cut and paste business. One could imagine creating a language that compiles reams of selected C code and yet is a language nothing like C, does not have features that the selected code does not exercise and would be roundly rejected as a C implementation. Heck I can cut and paste C code into JavaScript and have it run. Of course not. I'm betting that if one asked the question of someone making such a request they would have no idea themselves. They would just say "we want Python". A good approach.
My only claim is that creating a "not Python" language that is only superficially, syntactically, looking like Python to some extent is not the way to go. It's redundant as we have a ton of languages that work just as well or better on the Prop already. It's a confusion for any students as it looks like Python but is not. And it does not meet the request for "Python on the Propeller".
Ultimately the only way to resolve this is to build such a "Not Python" and see how well it flies. We look forward to seeing what you come up with.
Ken may even choose to call it something else, as your main reflex seems to be 'not python', even tho quite plainly a MCU is 'not a PC' either...
Control-Flow MCU Python would not confuse me, and underlines that a MCU is not a PC.
Yet strangely, Parallax are getting increasing requests for Python ? Hence this thread and the title itself.
Seems that "a ton of languages that work just as well or better on the Prop already" claim, is not resonating out there ?
Stepping back a little from the original question, given Parallax also need a successor to BS-2, they could instead grab a 2015 large 'MCU', (eg 2MBF.512KR, 200MHz) which can run MicroPython, and present that to their customer base, solving two problems at once.
https://docs.python.org/3.0/library/index.html
I think this is a good idea but I doubt it will ever fly. It seems like Parallax could take their considerable expertise in creating educational material and apply it to a board built around someone else's MCU. This is, of course, what they have already done with the BASIC Stamp. However, it seems that now any new educational offering must be based on the Propeller. A compromise might be to build a board with both an ARM and a Propeller and a version of Python that is tightly integrated with the Propeller as an I/O accessory but that has been suggested many times without any success.
Interactive is what any good remote-debugger offers, and compile and download times should be tolerably fast.
Certainly a PC_based compiler slashes the resource load on the MCU, and boosts performance.
Yes, a good idea, but I suspect the P2 is a distraction, as they hope more will fit into that.
A small-steps solution to your approach, would be a RaspPi slave board, that has the "version of Python that is tightly integrated with the Propeller as an I/O accessory" as part of the package.
The choice of which larger-ARM-MCU as a host is widening all the time - I see Spansion mention Graphics engines and HyperFLASH/HyperRAM interfaces in their next generation Automotice console 'MCUs', sampling soon.
That breaks the "few-MB" ceiling of even the larger MCUs, but keeps the pin-counts manageable.
Sure, but any MCU development loop, is never quite as interactive as a Native-PC loop.
Modern serial links can help slash the download times to most MCUs, tho the present Prop boot design needs some help ...
http://www.embeddedartists.com/products/boards/lpc4088_qsb.php
But I don't see Parallax going with any MCU they don't own the IP to.
...aaand:
The micropython port to the esp8266 WiFi modules is making progress.
WiFi is said to be at least kind of running but the esp8266 specific gpios are not supported yet...
Optimistic view: Within some weeks :-) or months :-( we'll have a $3 python coprocessor with WiFi abilities for the propeller...
Interesting, I'll need to check for that compile/download step when I'm using espruino, micropython, forth or micromite basic on various micros even Propforth or Tachyon on Propellers. It must be a REALLY short part of the development loop!
David has the chops to make a language with a Python like syntax. Skills of which I am envious. He also says he would not expect anyone to use it. I guess for the same reason people don't use a million other such experimental languages. Besides it's not what the customer ordered as far as I can tell. Ken would have to set us straight on that.
I'm not following the idea behind "an MCU is not a PC". That is clearly true. It's all a fuzzy distinction though. A modern MCU is faster and has more memory that the PC's we were using not long ago. JavaScript, Python, Lua and such are a reality on tiny, amazingly cheap micro-controllers. Who would want this "Control-Flow MCU Python"? What would they do with it? Apparently you are right. I cannot account for it. My conclusion is these guys don't want to teach the binary and hex and assembler and real-time concerns of the low level of the embedded or even "normal" computing world. But they want to use a tiny MCU. They are very confused:) They could...I suspect Chip would have something to say about that. Yes. I'm totally with you there. An idea I and others suggested the minute the Pi came out. Such a huge potential market and all neatly aligning with the educational activities of Parallax and the Raspberry Pi Foundation.
No special version of Python required for that. Perhaps a Propeller board interfacing library, and all the C and Spin tools for the Pi supported properly.
@David, Yep. Bill has been doing sterling work in that direction.
Over in England Pimoroni have come up with the beautiful "Propeller Hat" for the Raspi http://shop.pimoroni.com/products/propeller-hat complete with a Python IO library as it happens.
Don't let the Forth guys hear you say that
@yeti, I guess that is the way to get Python on the Prop. Use the Prop to make a terminal to a Python engine on your WIFI adater. Neat:)
@David, Could be. Around here just now is a thread going on about using an esp8266 WIFI adapter with the Propeller. Last I looked at that thread they seem to have come to the realization they can do what they want in Lua on the esp8266 and don't need the Propeller !
Command line 'interactive' is not quite the interactive modern student expect.
They certainly expect a syntax highlighting editor, that has other smarts like find declaration.