To 'with' or not to 'with': how is the question ?

Alex Martelli aleaxit at yahoo.com
Sun Sep 3 10:24:37 CEST 2000


"Daniel Dittmar" <daniel at dittmar.net> wrote in message
news:39B17A79.214FD56B at dittmar.net...
    [snip]
> def alternativeThree ():
>     with sys.stdout:
>         .write (...)
>         .write (...)
>         .write (...)

def alternativePython():
    for __ in [sys.stdout]:
        __.write(...)
        __.write(...)
        __.write(...)

I don't think we need a "syntax revolution" to let you
achieve basically the same structure as you can do today.


Maybe "with foo:" would be more direct than the
"for __ in [foo]:" syntax, but the latter has the Pythonic
advantage of letting you name the placeholder variable;
__ is OK, but others may like a style where the name
for the placeholder is less 'transparent', more explicit:

    for out in [sys.stdout]:
        out.write(...)
        out.write(...)
        out.write(...)

And of course the ability to specify the placeholder names
lets you nest these with-equivalents.


Implied/unexpressed variablenames are unPythonic.  E.g.,
most OO languages let you say "foo" within a method to
mean, implicitly, "the foo of this object I'm handling"; in
Python, "explicit is better than implicit", so you explicitly
say self.foo instead -- and it is good.  Reduces confusion,
etc.  So, if such explicit placeholders as 'self' are OK, and
one of Python's hallmarks, why not render the 'with' in a
very similar vein?  All that's left may be a vague desire for
smoother syntax-sugar, maybe
    with sys.stdout as __:
to replace
    for __ in [sys.stdout]:
but I, personally, doubt the usage frequency of 'with' is
sufficient to warrant a special-purpose subclassing of the
more general & useful for-syntax.


Alex






More information about the Python-list mailing list