"Chris Mellon" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list