On Fri, May 8, 2015 at 1:24 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: >> That's Python's job. Abstracting away all those differences so you >> don't have to look at them. > > That's the difference between our opinions: you want Python to work the > same on different OS's. I want Python's system programming facilities to > closely mirror those of C.
In that case, what you should do is devise an alternative language that compiles as a thin layer over C. Have a simple translation script that turns your code into actual C, then passes it along for compilation. You could add whatever Python-like features you want (memory management, maybe), but still be executing as C code. But you don't want a high level language, if your greatest goal is "closely mirror C". > Take your example of subprocess.Popen. It may be essential to know that > the communication channel is a pipe with standard pipe semantics. The > child program might not be written in Python, after all. In fact, at > system design level you shouldn't care what language you use as long as > the communication interfaces are specified. Ah, but that's a completely different thing. If you're working with a child that isn't written in Python, then you're not working at the level of the multiprocessing library - you're working with "I need to give this something on its stdin and get the result back from its stdout". For that, yes, you need something a bit more concrete; but now it's become part of the API for that child process, whereas the example I was giving was about the multiprocessing library, where it's part of the implementation. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
