threading support in python

[Paul Rubin]

"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

  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...