> The only cases I see the first school of thought is when the resource
> in question is "scarce" in some way.
By "resource" I meant anything with some sort of acquire/release
semantics. There may be plenty of threading.Locks available, but it's
still important that a given Lock is released when n
I will shamelessly point out my decorator module:
http://www.phyast.pitt.edu/~micheles/python/decorator.zip
The documentation is here:
http://www.phyast.pitt.edu/~micheles/python/documentation.htm
There is an example of redirecting stdout which is
relevant to this thread.
HTH,
Michele
Mike Meyer <[EMAIL PROTECTED]> writes:
> > When handling resources in Python, where the scope of the resource is
> > known, there seem to be two schools of thought:
> > (1) Explicit: ...
> > (2) Implicit: let the GC handle it.
>
> The only cases I see the first school of thought is when the resour
"John Perks and Sarah Mount" <[EMAIL PROTECTED]> writes:
> When handling resources in Python, where the scope of the resource is
> known, there seem to be two schools of thought:
>
> (1) Explicit:
> f = open(fname)
> try:
> # ...
> finally:
> f.close()
>
> (2) Implicit: let the GC handle i
John Perks:
> When handling resources in Python, where the scope of the resource is
> known, there seem to be two schools of thought:
> ...
This is part of what PEP 343 addresses:
http://www.python.org/peps/pep-0343.html
Neil
--
http://mail.python.org/mailman/listinfo/python-list
When handling resources in Python, where the scope of the resource is
known, there seem to be two schools of thought:
(1) Explicit:
f = open(fname)
try:
# ...
finally:
f.close()
(2) Implicit: let the GC handle it.
I've come up with a third method that uses decorators to achieve a
useful
