Python's "only one way to do it" philosophy isn't good?

[Chris Mellon]

On 6/28/07, Douglas Alan <doug at alum.mit.edu> wrote:
> "Chris Mellon" <arkanes at gmail.com> writes:
>
> > Obviously. But theres nothing about the with statement that's
> > different than using smart pointers in this regard.
>
> Sure there is -- smart pointers handle many sorts of situations, while
> "with" only handles the case where the lifetime of the object
> corresponds to the scope.
>

The entire point of RAII is that you use objects who's lifetime
corresponds with a scope. Smart pointers are an RAII technique to
manage refcounts, not a resource management technique in and of
themselves.


> > To the extent that your code ever worked when you relied on this
> > detail, it will continue to work.
>
> I've written plenty of Python code that relied on destructors to
> deallocate resources, and the code always worked.
>

This is roughly equivilent to someone saying that they don't bother
initializing pointers to 0 in C, because it's always worked for them.
The fact that it works in certain cases (in the C case, when you're
working in the debug mode of certain compilers or standard libs) does
not mean that code that relies on it working is correct.

> > There are no plans to replace pythons refcounting with fancier GC
> > schemes that I am aware of.
>
> This is counter to what other people have been saying.  They have been
> worrying me by saying that the refcounter may go away and so you may
> not be able to rely on predictable object lifetimes in the future.
>

Well, the official language implementation explicitly warns against
relying on the behavior you've been relying on. And of course, for the
purposes you've been using it it'll continue to work even if python
did eliminate refcounting - "soon enough" deallocation of non-time
sensitive resources. So I don't know what you're hollering about.

You're arguing in 2 directions here. You don't want refcounting to go
away, because you rely on it to close things exactly when there are no
more references. On the other hand, you're claiming that implicit
management and its pitfalls are fine because most of the time you
don't need the resource to be closed in a  deterministic manner.

If you're relying on refcounting for timely, guaranteed,
deterministic resource managment then your code is *wrong* already,
for the same reason that someone who assumes that uninitialized
pointers in C will be 0 is wrong.

If you're relying on refcounting for "soon enough" resource management
then it'll continue to work no matter what GC scheme python may or may
not move to.

> > Nothing about Pythons memory management has changed. I know I'm
> > repeating myself here, but you just don't seem to grasp this
> > concept.  Python has *never* had deterministic destruction of
> > objects. It was never guaranteed, and code that seemed like it
> > benefited from it was fragile.
>
> It was not fragile in my experience.  If a resource *positively*,
> *absolutely* needed to be deallocated at a certain point in the code
> (and occasionally that was the case), then I would code that way.  But
> that has been far from the typical case for me.
>

Your experience was wrong, then. It's fragile because it's easy for
external callers to grab refcounts to your objects, and it's easy for
code modifications to cause resources to live longer. If you don't
*care* about that, then by all means, don't control the resource
explicitly. You can continue to do this no matter what - people work
with files like this in Java all the time, for the same reason they do
it in Python. Memory and files are not the end all of resources.

You're arguing against explicit resource management with the argument
that you don't need to manage resources. Can you not see how
ridiculously circular this is?