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

[Douglas Alan]

Lenard Lindstrom <len-l at telus.net> writes:

>> Also, any caught exception is automatically cleared when
>> the catching procedure returns anyway, so it's not like Python has
>> ever considered a caught exception to be precious information that
>> ought to be preserved long past the point where it is handled.

> That's the point. Python takes care of clearing the traceback. Calls
> to exc_clear are rarely seen.

But that's probably because it's very rare to catch an exception and
then not return quickly.  Typically, the only place this would happen
is in main(), or one of its helpers.

> If they are simply a performance tweak then it's not an issue *. I
> was just concerned that the calls were necessary to keep resources
> from being exhausted.

Well, if you catch an exception and don't return quickly, you have to
consider not only the possibility that there could be some open files
left in the traceback, but also that there could be a large and now
useless data structures stored in the traceback.

Some people here have been arguing that all code should use "with" to
ensure that the files are closed.  But this still wouldn't solve the
problem of the large data structures being left around for an
arbitrary amount of time.

> But some things will make it into ISO Python.

Is there a movement afoot of which I'm unaware to make an ISO standard
for Python?

> Just as long as you have weighed the benefits against a future move
> to a JIT-accelerated, continuation supporting PyPy interpreter that
> might not use reference counting.

I'll worry about that day when it happens, since many of my calls to
the standard library will probably break anyway at that point.  Not to
mention that I don't stay within the confines of Python 2.2, which is
where Jython currently is.  (E.g., Jython does not have generators.)
Etc.

>> I think that Jython and IronPython, etc., should adopt these
>> semantics, but I imagine they might not for performance reasons.  I
>> don't generally use Python for it's speediness, however, but rather
>> for it's pleasant syntax and semantics and large, effective
>> library.

> Yet improved performance appeared to be a priority in Python 2.4
> development, and Python's speed continues to be a concern.

I don't think the refcounting semantics should slow Python down much
considering that it never has aimed for C-level performance anyway.
(Some people claim it's a drag on supporting threads.  I'm skeptical,
though.)  I can see it being a drag on something like Jython, though,
were you are going through a number of different layers to get from
Jython code to the hardware.

Also, I imagine that no one wants to put in the work in Jython to have
a refcounter when the garbage collector comes with the JVM for free.

|>oug