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

[Douglas Alan]

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

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

> For the record, C++ doesn't have a BDFL.

Yes, I know.

   http://dictionary.reference.com/browse/analogy

> And yes, I know that it's used all the time in C++ and is heavily
> encouraged. However, C++ has totally different object semantics than
> Python,

That would depend on how you program in C++.  If you use a framework
based on refcounted smart pointers, then it is rather similar.
Especially if you back that up in your application with a conservative
garbage collector, or what have you.

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

> I have an overwhelming urge to say something vulgar here. I'm going
> to restrain myself and point out that this isn't a discussion about
> expressiveness.

Says who?

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

> It's a perfect analogy, because the value of an uninitialized pointer
> in C is *implementation dependent*.

Name one common C implementation that guarantees that uninitialized
pointers will be initialized to null.  None that I have *ever* used
make such a guarantee.  In fact, uninitialized values have always been
garbage with every C compiler I have ever used.

If gcc guaranteed that uninitialized variables would always be zeroed,
and you knew that your code would always be compiled with gcc, then
you would be perfectly justified in coding in a style that assumed
null values for uninitialized variables.  Those are some big if's,
though.

> The Python language reference explicitly does *not* guarantee the
> behavior of the refcounter.

Are you suggesting that it is likely to change?  If so, I think you
will find a huge uproar about it.

> By relying on it, you are relying on an implementation specific,
> non-specified behavior.

I'm relying on a feature that has worked fine since the early '90s,
and if it is ever changed in the future, I'm sure that plenty of other
language changes will come along with it that will make adapting code
that relies on this feature to be the least of my porting worries.

> Exactly like you'd be doing if you rely on the value of
> uninitialized variables in C.

Exactly like I'd be doing if I made Unix system calls in my C code.
After all, system calls are implementation dependent, aren't they?
That doesn't mean that I don't rely on them every day.

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

> Of course not. Because they *do* guarantee and specify that. C
> doesn't, and neither does Python.

CPython does by tradition *and* by popular will.

Also the language reference manual specifically indicates that CPython
uses a refcounter and documents that it collects objects as soon as
they become unreachable (with the appropriate caveats about circular
references, tracing, debugging, and stored tracebacks).

|>oug