[Edu-sig] Re: A better way?

[Beni Cherniavsky]

Jeff Sandys wrote:
> -- Beni Cherniavsky <cben at users.sf.net> wrote:
> 
>> It's important that they realize that the dot is not a 
>> pure operator as the rest of Pythons operators: the thing 
>> on its right side is not an arbitrary expression but an 
>> identifier.  So you can't do ``foo . (bar + baz)`` the way 
>> you can do ``foo * (bar + baz)``.  Showing the equivallence 
>> to `getattr()` is a nice way to demonstarte the fact the 
>> right argument is not an expression evaluated in the current environment but actually just a string.
>> 
> There you go making dot (.) a special operator.  ;-> 
> It is no more special than plus (+), star (*), or 
> percent (%).  As you said objects need to have a __getattr__ 
> method for dot to work just as they need __add__ method for 
> plus to work, __mul__ method for star to work and __mod__ 
> method for percent to work.  Both numbers and strings have 
> all three methods.  The thing on the left or right is never 
> an arbitrary expression, it is an object that might have 
> the corresponding method for the given operator.

Sure, at run-time a __getattr__ call is just like any other magic method. 
What I meant that the dot is a bit special *syntactically*.  The thing on the 
left of the dot can be any expression.  Its value should be an object with the 
expected attribute or you would get an exception but syntactically it can be 
any expression whatsoever.  However, syntactically, the thing on the right of 
the dot is special: it's not an expression at all.  As I said, you can't do 
``foo.(bar+baz)`` - it's a syntax error.   It's an identifier which is taken 
as a string, not evaluated in the current environment.  ``foo.bar`` is not not 
related to the variable `bar` in the current environment in any way. 
``foo+bar`` is.

-- 
Beni Cherniavsky <cben at users.sf.net>, who can only read email on weekends.