[Tutor] With

[Jeff Shannon]

Blake Winton wrote:

>This problem could be avoided if you had to prefix any "with"-ed
>variables with a ".", or something, so the example would look like:
>
>with this_long_thing
>    foo = 2;
>    .bar = 'bat';
># "do" and "done" ommitted to make it more Pythonic.
>
>Which would indicate that the only thing that came from
>"this_long_thing" was the "bar".  That _might_ not be so bad.  Still a
>little ugly, in my opinion, but clearly in the realm of opinion, and
>not a bad idea.  Of course, I'm still a little unclear about the scope
>of the resulting "foo" variable.  Should it go away at the end of the
>"with"-block?  Wouldn't that make the "with"-block less useful?)
>

Well, loops never create a new scope in Python (only classes and 
functions do that) so the "foo" in this example will be in the same 
scope as if the above were spelled

foo = 2
this_long_thing.bar = 'bat'

I most definitely agree, though that *IF* 'with' were to be added to 
Python, it would be a travesty to not require some indicator (such as 
the leading period) of which names were attributes of the 'with' 
subject, and which were independent variables.  "Explicit is better than 
implicit."  Otherwise, we'd be right back to the same problems created 
by C++'s implicit 'this' pointer, complete with ugly naming conventions 
("a leading 'm_...' indicates a class member", etc).  This is a road 
that I do *not* want to see Python taking.

Personally, I don't see that much point to 'with'.  As others have said, 
it doesn't really accomplish much except for, in the mind of *some* 
people, a "more clear and intuitive" look.  I find it less clear than a 
temporary variable, myself...  but then, I usually don't bother with 
temporary variables, and instead just suck it up and type out the whole 
long name, because explicit is better than implicit and I'll be more 
able to follow this code in three months' time when I have to maintain 
it.  Actually, I rarely have big long identifier chains anyhow -- I keep 
identifier names relatively short, and if I need to use a chain of 
attributes more than once, I tend to presume that this action belongs in 
a method anyhow.  In other words, I wouldn't write

myobject.subobject.field.add(x)
myobject.subobject.field.verify()
myobject.subobject.field.format()

Instead, I'd have a subobject.modify_field() method...

def modify_field(self, fieldname, x):
    field = getattr(self, fieldname)
    field.add(x)
    field.verify()
    field.format()

myobject.subobject.modify_field(field, x)

Thus, I'm using a well-defined method in the same sort of way that 
someone might use 'with'.  I tend to feel that almost any situation 
where 'with' is really useful, is probably a situation where the Law of 
Demeter is being violated, and therefore the solution is not a construct 
that lets me type less, but instead an attempt to refactor.
   
However, as has been said before, if anyone wants to discuss this 
seriously, then the discussion really ought to be moved over to 
comp.lang.python where it might actually accomplish something.  :)

Jeff Shannon
Technician/Programmer
Credit International