> Not arguing against closed source - per se. But if that is important to > industry, let industry bear the training costs. > > > Art
I don't yet have a clear grasp of what parts of the .NET architecture would be closed to a Python developer. Good question though. In the case of Mono, the .NET clone for Linux, you can get the source code, including for the C# compiler. And even on MSFT, there's nothing to keep Python developers from sharing their .py source files -- they'd compile to the CLR when first run, then wouldn't need to be recompiled again (like now, with .pyc files, which any developer may share in lieu of .py files). The situation with Jython is comparable. You can share the source, or just ship the .class files. Either way, the source for the platform-specific JVM itself (e.g. Sun's) may not be open to you. Most Windows users of Python are aware the source is available, but few compile it, as Windows doesn't even include a free compiler. And look at the Win32 extensions module, available with all Windows versions -- that sends hooks deep into the Windows OS, lets you deal with COM objects and provides bindings to the Microsoft Foundation Classes (MFC). That stuff is all proprietary/closed, even if Mark Hammond's win32 source isn't. I don't know to what extent Jim's project at Microsoft is going to yield a transparent stack, i.e. will all the C# code for implementing Python atop the .NET framework be open? If not, I'd expect the Python community to come up with another version that was. The metaphor of a stack (stuff on top of stuff) is a good one. On the Windows side, you always come down to a closed kernel at the bottom, so your Python can't be considered "pure open source all the way down to the chip" no matter what you do. Besides, the chip itself is proprietary (Intel or AMD inside). Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
