Any modern operating system that allows open development fits the bill. I think what the OP is saying is that he would settle for having it run on top of Linux, but I'd bet that he wants the core written as (or even interpreted by) a Python interpreter, so that everything from drivers to applications could be written in Python. Wouldn't we all?
I've been wanting the same for Ruby, which I think is superior to Python in its syntax, clarity, and readability. I'd settle for a Ruby interpreter in every browser.
However, first, I'd like to see Firefox OS succeed. The idea behind it is better: take the most well-used web development language (client-side) and make it also the same language for writing applications (client-side). The only things missing are being able to write lower-level drivers using Javascript (not just having to hack atop Android) and for all of the server (not just Node) to be Javascript.
There is a reason that what is usually used to write OS's is basically C (or some variation), though. C is an intelligible and useful language that can be portable across architectures. C, Javascript, Python, Ruby, Java, etc. are all very similar when compared with assembly or machine code. C has the advantage of allowing more flexibility in memory management. So, I just don't see Python as an language used to develop an OS.
As for whether it makes sense to develop the appearance of everything being in Python so that kids can hack it up: you'd be better off introducing them to Scratch, Lego Mindstorms, the Arduino and have them participate in Science Olympiads. There is no modern equivalent of what we grew up with.
Instead of vanilla Python shell, I'd use IPython instead. It has all the run/save/load stuff you mention, and tons of other things to make Python nicer to use interactively. IPython also has Qt-based console, which has the ability to display rich content inline. I think the ability to interact with graphical subsystems is important, look at C64 demoscene to see what idle kids can do with even with primitive graphics system.
booting into an IPython QT shell in full screen, with a custom help message explaining how to save hunks of code to file, would be great. Being able to Alt+Tab to a browser (even one pointing at a local copy of the python and ipython docs) would be essential, though.
I only ran into this a couple days ago and have obviously never even conceived of checking it out, but it seems to have been purpose-built to have a modern-day equivalent of the old hackable OSes of the 80s:
You could boot your machine into a LISP or Scheme repl, which in my opinion (as a ruby programmer by trade) are much nicer for kids to learn programming with than Ruby or Python because of the dynamic and interactive nature of lisp.
I have experimented with it. The worst problem I had was that the terminal emulators were too slow for my taste. But overall, Emacs works surprisingly well for it.
If taking this route, maybe emulating one of the old lisp machines would be a good way to go (since they really were lisp all the way down). It looks like someone has already started this project. http://www.unlambda.com/l-machine/l-machine.html
I have similar fond memories of using Acorn and Sinclair systems when I was younger: turn it on and start hacking away.
Of course, in those days, everything was simpler, and for all the benefits that the modern, heterogeneous technology landscape offers us, I do think we’ve lost something by trying to make everything do everything for everyone while talking to everything else.
The people best placed to fix that are the ones who control both the hardware and the software foundation running on it, but sadly, the most obvious examples like Apple and the games console makers seem to want just about the most locked-down, developer-hostile environments in computing history.
That all said, today’s kids have the benefits of the Internet and the vast potential it offers for teaching, learning, sharing and collaborating, all on a scale we couldn’t even dream of when I was first learning to program. I wonder whether that ecosystem combined with recent hardware developments like the Raspberry Pi might offer enthusiastic youngsters a very different experience but one that ultimately encourages their interest as well or better than what we had in my generation.
There's http://www.pycorn.org , an interpreted OS written in python. Although it's "in a very early stage, and is unlikely to be interesting to users who are not low-level developers."
What's wrong with learning kids Shell scripting? I think most Unix-like OS's are good for learning, behind the complex layers of abstractions lay the simple command line. Excellent for programming without any distraction.
Assuming you mean bash-like shells on Unix boxes, quite a few things:
1. Commands have arbitrary, hard-to-remember names.
2. Destructive commands tend not to issue warnings.
3. Mass destructive commands still tend not to issue warnings.
4. Did I mention that destructive commands don't tend to issue warnings?
5. Destructive commands typically can't be undone.
A system where you can do a lot of permanent damage without warning and where the names of things are mostly guesswork is a terrible environment for experimentation, and experimentation is often the best way to learn a new technology.
I meant that you should setup a simple environment, setting up a partition and chroot into it. Learn the kid to use man(1) and ed(1) and after that let him/her play around. I heard someone doing this with his 5 year old kid on the OpenBSD mailing-list, that kid will probably be able to write quite useful scripts in a few years.
Why should you teach a child ed(1), instead of any other text editors?
In my opinion , it is one of the most sadistic common text editors in existence, and has been for several decades.
To be fair, Python's shutil.rmtree() won't give you any warnings either.
Sure, and that's why I don't think modern general-purpose programming languages like Python are a particularly good substitute for the BASICs of old as a default environment.
If the idea is to encourage kids to learn more about the technology they're using, one of the most basic requirements is a safe system they can use without any danger of causing serious damage.
And there's a limit on your ability to destroy stuff if you're not running as root.
That assumes your system has a concept of root, which in turn assumes your system has a concept of users at all and a robust security model. I'm not sure any of those things is necessary, or even desirable, for the kind of system we're thinking about here. I think the correct requirement is "User can not cause any permanent damage", and if things like Linux or Windows or Python or Ruby can't meet that requirement, then they simply aren't the tools we're looking for in this particular context.
You could just set up an isolated system with nothing you care about holding onto for them. Destructive commands would, at worst, require a full wipe and re-image and probably a short conversation about what the fuck just happened.
The most productive time in my educational career was when I built PCs, loaded every OS I could find, and destroyed them. As long as it isn't the same system as your tax records, its great.
Nowdays with VMs, snapshots, and partition editors, learning can be accelerated.
all of the above are great for well supported kids to learn about firsthand. resillience and perseverance are great traits to acquire young, especially when coupled with a healthy awareness of your own fallibility.
In that family, Inferno is a small complete OS, which runs as a virtual machine on a Windows/Linux/MacOS host. All source code is included, so it's hackable, and it improves (wrt the basics) on the Linux state of the art. Acme, especially with the plumber, is more friendly user interface than the terminal command line. http://www.vitanuova.com/inferno/
Biggest problem for this issue today is: kids don't know what a command line is, and are unfamiliar with the classic "terminal" interface.
When teaching an intro to programming, my curriculum still uses this "command shell" form. Of late, nigh unto no students have seen it, and I have to teach it as a new concept - a problem as it's more obsolete than new. Soon we'll have to give up on it as a starting point, saving it for more advanced students. GUIs rule now; beginners don't grok a text prompt.
I like the ideas behind http://acko.net/blog/on-termkit/. I too dream of a ipython-like shell, where the input/output is similar to GET/POST with Accept headers (so the pipes know if the source/destination can manage the data).
But the problem is that do this is hard, take time, and to be useful, require rewrite a lot of basic unix functionality (however, a compatibility can be archived, as with ipython !command) and perhaps a custom language/interpreter to make it usable.
I've been wanting the same for Ruby, which I think is superior to Python in its syntax, clarity, and readability. I'd settle for a Ruby interpreter in every browser.
However, first, I'd like to see Firefox OS succeed. The idea behind it is better: take the most well-used web development language (client-side) and make it also the same language for writing applications (client-side). The only things missing are being able to write lower-level drivers using Javascript (not just having to hack atop Android) and for all of the server (not just Node) to be Javascript.
There is a reason that what is usually used to write OS's is basically C (or some variation), though. C is an intelligible and useful language that can be portable across architectures. C, Javascript, Python, Ruby, Java, etc. are all very similar when compared with assembly or machine code. C has the advantage of allowing more flexibility in memory management. So, I just don't see Python as an language used to develop an OS.
As for whether it makes sense to develop the appearance of everything being in Python so that kids can hack it up: you'd be better off introducing them to Scratch, Lego Mindstorms, the Arduino and have them participate in Science Olympiads. There is no modern equivalent of what we grew up with.