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

[Douglas Alan]

Steve Holden <steve at holdenweb.com> 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