Could Emacs be rewritten in Python?
Christian Tanzer
tanzer at swing.co.at
Mon Apr 14 13:01:41 EDT 2003
Robin Munn <rmunn at pobox.com> wrote:
> Paul Foley <see at below.invalid> wrote:
> > 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?
Disclaimer: I'm not arguing for adding dynamic scopes or variable
declarations to Python <wink>.
I see three problems with try/finally for temporary rebindings of
multiple variables:
- It is fragile for multiple rebindings unless you save all the old
values before the try.
- It is easy to forget/inadvertantly delete some restore operations in
the finally clause.
- It destroys locality of reference for the human reader. Your toy
example needs eight try/finally lines vs. three lines for the
alternative solution. For multiple rebindings, the ratio gets worse.
Still-greatly-preferring-Python-over-Lisp-ly yr's,
--
Christian Tanzer tanzer at swing.co.at
Glasauergasse 32 Tel: +43 1 876 62 36
A-1130 Vienna, Austria Fax: +43 1 877 66 92
More information about the Python-list
mailing list