On Nov 24, 10:07 am, Duncan Booth <[EMAIL PROTECTED]>
wrote:
> Ton van Vliet <[EMAIL PROTECTED]> wrote:
>
> > It would boil down to choice: explicit/speed vs implicit/readability
>
> No, it would boil down to explicit+speed+readability+maintainability vs
> implicit+error prone.
>
> It would mean that as well as the interpreter having to search the
> instance to work out whether each name referenced an attribute or a global
> the reader would also have to perform the same search. It would mean that
> adding a new attribute to an instance would change the meaning of the
> methods which is a recipe for disaster.
Besides Pascal, Visual Basic also offers a 'with' statement that
behaves almost in this way. That in itself should be an indication
that the whole thing is a bad idea. ;-)
The way it works, however, is that you do have to prefix members with
a '.' and the interpreter tries to bind with each nested 'with'
variable in turn. It's tolerable with one 'with' statment, but once
you start nesting them it becomes dangerous.
My idea in a parallel thread is to treat a '.' prefix like '../' in
file paths; each one moves you up a level in the symbol table. In a
top-level function, it means a global name; in a class method it means
a member. The @classmethod and @staticmethod decorators would need to
fix things so that '.' refers to the appropriate things. There's no
reason why a 'using' statement couldn't perform nesting as well: '.'
refers to the 'using' variable, '..' refers to what '.' previously
referred to, etc.
OTOH, the point of 'using' is to reduce typing, so you might instead
add 'as' clauses as an alternate way to reduce confusion:
>>> using myclass.new() as p:
p.do_something()
p.something_else()
Of course, now its starting to look more like a Python 'with'
statement, and I think there's a way to do basically this already.
--
http://mail.python.org/mailman/listinfo/python-list
