Steve Holden <[EMAIL PROTECTED]> writes: >> 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.
> Damn, it seems to be broken on my Jython/IronPython installations, > maybe I should complain. Oh no, I can't, because it *isn't* *part* > *of* *the* *language*. ... As I have mentioned *many* times, I'm coding in CPython 2.5, and I typically make extensive use of Unix-specific calls. Consequently, I have absolutely no interest in making my code compatible with Jython or IronPython, since Jython is stuck at 2.2, IronPython at 2.4, and neither provide full support for the Python Standard Library or access to Unix-specific functionality. I might at some point want to write some Jython code to make use of Java libraries, but when I code in Jython, I will have absolutely no interest in trying to make that code compatible with CPython, since that cannot be if my Jython code calls libraries that are not available to CPython. >>> 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. > That depends on whether you program to a specific standard or not. What standard would that be? Posix is too restrictive. BSD/OSX/Linux/Solaris are all different. I make my program work on the platform I'm writing it for (keeping in mind what platforms I might want to port to in the future, in order to avoid obvious portability pitfalls), and then if the program needs to be ported eventually to another platforms, I figure out how to do that when the time comes. >>> 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. > But you make the mistake of assuming that Python is CPython, which it isn't. I do not make that mistake. I refer to CPython as "Python" as does 99% of the Python community. When I talk about Jython, I call in "Jython" and when I talk about "IronPython" I refer to it as "IronPython". None of this implies that I don't understand that CPython has features in it that a more strict interpretation of the word "Python" doesn't necessarily have, just as when I call a tomato a "vegetable" that doesn't mean that I don't understand that it is really a fruit. >> 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). > Indeed, but that *is* implementation dependent. As long as you stick > to CPython you'll be fine. That's allowed. Just be careful about the > discussions you get into :-) I've stated over and over again that all I typically care about is CPython, and what I'm criticized for is for my choice to program for CPython, rather than for a more generalized least-common-denominator "Python". When I program for C++, I also program for the compilers and OS'es that I will be using, as trying to write C++ code that will compile under all C++ compilers and OS'es is an utterly losing proposition. |>oug -- http://mail.python.org/mailman/listinfo/python-list
