"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Having memory protection is superior to not having it--OS designers > spent years implementing it, why would you toss out a fair chunk of it? > Being explicit about what you're sharing is generally better than not.
Part of the win of programming in Python instead of C is having the language do memory management for you--no more null pointers dereferences or malloc/free errors. Using shared memory puts all that squarely back in your lap. > I disagree with this, though. The benefits of deterministic GC are > huge and I'd like to see ref-counting semantics as part of the language > definition. That's a debate I just had in another thread, though, and > don't want to repeat. That's ok, it can be summarized quickly: it lets you keep saying def func(filename): f = open(filename) do_something_with(f) # exit from function scope causes f to automagically get closed, # unless the "do_something_with" didn't know about this expectation # and saved a reference for some reason. instead of using the Python 2.5 construction def func(filename): with open(filename) as f: do_something_with(f) # f definitely gets closed when the "with" block exits which more explicitly shows the semantics actually desired. Not that "huge" a benefit as far as I can tell. Lisp programmers have gotten along fine without it for 40+ years... -- http://mail.python.org/mailman/listinfo/python-list