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

[Douglas Alan]

"Chris Mellon" <arkanes at gmail.com> writes:

> Sure, but thats part of the general refcounting vs GC argument -
> refcounting gives (a certain level of) timeliness in resource
> collection, GC often only runs under memory pressure. If you're
> saying that we should keep refcounting because it provides better
> handling of non-memory limited resources like file handles, I
> probably wouldn't argue. But saying we should keep refcounting
> because people like to and should write code that relies on implicit
> scope level object destruction I very strongly argue against.

And why would you do that?  People rely very heavily in C++ on when
destructors will be called, and they are in fact encouraged to do so.
They are, in fact, encouraged to do so *so* much that constructs like
"finally" and "with" have been rejected by the C++ BDFL.  Instead, you
are told to use smart pointers, or what have you, to clean up your
allocated resources.

I so no reason not to make Python at least as expressive a programming
language as C++.

>> > Relying on the specific semantics of refcounting to give
>> > certain lifetimes is a logic error.
>> >
>> > For example:
>> >
>> > f = some_file() #maybe it's the file store for a database implementation
>> > f.write('a bunch of stuff')
>> > del f
>> > #insert code that assumes f is closed.

>> That's not a logic error if you are coding in CPython, though I agree
>> that in this particular case the explicit use of "with" would be
>> preferable due to its clarity.

> I stand by my statement. I feel that writing code in this manner is
> like writing C code that assumes uninitialized pointers are 0 -
> regardless of whether it works, it's erroneous and bad practice at
> best, and actively harmful at worst.

That's a poor analogy.  C doesn't guarantee that pointers will be
initialized to 0, and in fact, they typically are not.  CPython, on
other other hand, guarantees that the refcounter behaves a certain
way.

There are languages other than C that guarantee that values are
initialized in certain ways.  Are you going to also assert that in
those languages you should not rely on the initialization rules?

|>oug