too many self

[Bengt Richter]

On Fri, 17 Sep 2004 08:54:11 +0200, aleaxit at yahoo.com (Alex Martelli) wrote:

>aurora <aurora00 at gmail.com> wrote:
>   ...
>> I'm not making any serious criticism on the language or how it should do
>> name binding. I'm ranting about having to attach a prefix to names often
>> make simple things look complicated. An annoyance when it has to be done
>> very often. You got the point?
>
>No.  If you had to "attach a prefix", it might perhaps be a problem.
>But, in Python, you don't have to do any such thing.  You use bare names
>for locals, globals, and built-ins, and compound names for attributes of
>objects.  How can it "make simple things look complicated" to use a
>compound name for an object attribute?  It indicates exactly what's
>going on: you're accessing or rebinding an attribute -- no more, no
>less.  Just like, e.g., x[i] is how you refer to an item of x, so is
>x.foo how you refer to an attribute of x.
>
>If what you mean to say (as opposed to what you actually wrote) is to
>support some kind of 'with' or 'using' statement, such as:
>
>with glek[idx]:
>    .total += .partial
>    .partial = current_time
>    .laps += 1
>
>so that several accesses to, and rebindings of, attributes of the same
>object, can be compactly and conveniently indicated, that, of course, is
>quite a different issue, which has often been discussed in the past,
>both here and on python-dev.  Yet there isn't even a PEP for it, yet, I
>believe -- a bad sign: it suggests nobody is keen enough on it to
>summarize the case for and against and nail down the specs.  I guess the
>problem is that if you see this as equivalent to, say:
>
>_ = glek[idx]:
>_.total += _.partial
>_.partial = current_time
>_.laps += 1
>
>it's not all that clear that the with notation is buying you all that
>much -- visually distinguishing that current_time is not an attribute
>name is about as hard in both cases, for example, maybe a bit harder if
>the hypothetical new construct were in use... and without said
>hypothetical new construct you have a better chance to make your code
>clearer by using a visually distinguished name rather than a notation
>which appears to try to HIDE the crucial issue of which name are bare
>ones, and which names are compound!
>
>Richer semantics for 'with'/'using' are of course possible, but harder
>to pin down in detail, and even more controversial.  Still, until
>somebody DOES care enough, for or against, to come up with a PEP, rather
>than rants on this NG, nothing much is going to happen re this idea.
>
It occurs to me that "with obj_expr:" selects a specific name space and
access mechanism (attribute access, which looks through base classes for
decriptors etc), whereas one could expand the concept of what the leading
dot means as an access operation. E.g., the normal default spelled out might be

    with(glek[idx], dotop=with.attr): # with.attr would be a get/set pair for attributes
        .total += .partial
        ...

Or you could limit yourself to an instance dict by alternate meaning
for '.' access, e.g.,

    with(vars(inst), dotop=with.item): # with.item would be get/set for items
        .total += .partial # meaning v=vars(inst); v['total'] += v['partial']; del v
        ...

or you could specify a list of spaces to chase in explicit order, e.g.,
object attribute spaces:

    with(a,b,c):
        x = .xxx # a.xxx if avail, else b.xxx, else c.xxx, else AttributeError

Anyway, you get the general idea. A way to spell out access to any alternative
name space or search path through several. ;-)

Regards,
Bengt Richter