threading support in python
Wed Sep 6 02:31:11 CEST 2006
"sjdevnull at yahoo.com" <sjdevnull at yahoo.com> 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
f = open(filename)
# 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
with open(filename) as 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...
More information about the Python-list