Could Emacs be rewritten in Python?

Carl Banks imbosol-1050446750 at
Wed Apr 16 01:12:58 CEST 2003

Alexander Schmolck wrote:
> Robin Munn <rmunn at> writes:
>> Paul Foley <see at below.invalid> wrote:
>> > On Mon, 14 Apr 2003 16:50:40 GMT, Robin Munn wrote:
>> > 
>> >> 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?
>> > 
>> > What if another thread (B) does the same thing, and changes sys.stdout
>> > while this thread (A) is still inside the "try" block?  And if thread
>> > A runs its "finally" clause and resets sys.stdout while thread B is
>> > still in its "try" block, they screw each other.
>> This is the classic problem that arises when two threads need to use any
>> shared resource, isn't it? I wasn't considering threads at all when I
>> wrote those two code samples, so of course I didn't use locks to ensure
>> good behavior.
>> Actually, now that I start thinking about it, any kind of
>> save-and-restore mechanism would start to get pretty hairy around
>> threads, wouldn't it? 
> Yes and that's why dynamic variables *do* make a real difference: different
> threads don't have to share the same global variable.

Dynamic variables are unnecessary.  Since rebinding sys.stdout is
utterly stupid, dynamic variables or not, I will use your logging
level example:

    oldlevel = log_level[thread.get_ident()]
    log_level[thread.get_ident()] = 10
        log_level[thread.get_ident()] = oldlevel

Encapsulate this into a few functions, and you get something easy like

    oldlevel = logging.set_level(10)

There.  Without the use of dynamic globals, there is a simple system
in place to temporarily change something.  No dynamically-scoped
variables necessary.

Seeing that temporarily changing a global variable like this is such a
fringe concern, and can easily be handled *in a thread-safe manner*
with a try ... finally, I don't see any justification whatsoever for
the infamously bug-prone dynamically scoped variables.


More information about the Python-list mailing list