Could Emacs be rewritten in Python?

[Robin Munn]

Paul Foley <see at below.invalid> wrote:
> On Mon, 14 Apr 2003 05:52:31 GMT, Carl Banks wrote:
> 
>> Ok, let me back off a bit.  That you might want to change a program's
>> state in a dynamic scope is reasonable.
> 
>> Typically, however, that kind of thing should be handled by passing
>> objects around as arguments.  For example, consider the use of current
>> buffer in Emacs.  (We are still leaving Emacs issues out of it; I'm
>> just using it as an example of bad programming.)  Most functions in
>> Emacs operate on the current buffer, a piece of global state.  In
>> order to operate on a non-current buffer, you have to temporarily
>> change the current buffer.  That is bad programming; functions should
>> take the buffer to operate on as an argument.
> 
> Don't forget the ~20000 other variables that you'd have to pass around
> as explicit arguments to *every single function*.
> 
> Good luck trying to maintain that code!
> 
>> However, I think changing a global value within a dynamic scope, in
>> situations where it wouldn't be better to pass around an argument, is
>> a very uncommon concern. 
> 
> Well, you think wrong.
> 
>> So if you need that kind of thing, please don't destroy the language
>> by adding dynamic scoping.  Just live with a try ... finally.
> 
> I.e., write broken and fragile code just to avoid a perfectly good
> construct that you happen to dislike for religious reasons.
> Brilliant!

How is try ... finally "broken and fragile code"? How is this:

    try:
        old_stdout = sys.stdout
        new_stdout = cStringIO.StringIO()
        sys.stdout = new_stdout
        function_whose_output_I_want_to_capture()
        do_something_with(new_stdout)
    finally:
        sys.stdout = old_stdout

in any way inferior to this (making up a semi-Pythonic syntax):

    with sys.stdout = cStringIO.StringIO():
        function_whose_output_I_want_to_capture()
        do_something_with(sys.stdout)

Yes, sample #2 is shorter. But it would require adding a new keyword to
the language, which is a pretty heavy price to pay. And sample #2
doesn't need a temporary variable -- but sample #1's temporary variable
is a function-local variable, so speed and namespace-clutter costs are
minimal.

What I really want to know is why you would consider sample #1 "broken
and fragile code". I can't think of any circumstances where sample #1
would fail to achieve its desired effect. Can you?

-- 
Robin Munn <rmunn at pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838    50FF 2478 CFFB 081A 8338  54F7 845D ACFD 6AFB 6838