Why self?

[- c o v e n t r y -]

> 2) How do you reference variables that aren't in the specified
> namespace without a second keyword!


I see what you're saying: assume you enforce the same sort of 
namespace-lookup rules
in place, extended to the 'with' keyword:

a) look in the object specified by the with clause for the name
b) look in the local scope
c) look in the global scope

This limits the effectiveness of 'with' severely.

> 3) Issue 2 becomes critical when you what to deal with temporary
> results that you definately want discarded along with the current
> local scope.  So maybe only rvalues are affected ie.
> 
> with self:
>     self.y = x**2 * t/z + a * FFT(tseries)
> 
> might be better, but then the inconsistency bites.


Yes, 'the inconsistency bites', too much.

why not simply set a local to reference self?

a = self
a.y = a.x**2 * a.t/a.z + a.a * FFT(a.tseries)

This is still not as elegant (from certain points of view) as a 'with'
capability, but results in much shorter, easier to read code, and is
equivalent to the evolved 'with' clause utilizing 'as' to specify
a true name for the new namespace...

with self as a:
     a.y = a.x**2 * a.t/a.z + a.a * FFT(a.tseries)

this 'as' statement would be required, most likely, to avoid having
'magic names' for the default namespaces, to allow access to a local or 
global of the same name... such as Zope's PARENT[] list of namespaces.
If we're going to add magic names, maybe some like $_ and $@ should
be considered?  j/k ;)

anyway, I did a Very simply test to ensure binding a local to self 
works.  and it does:

 >>> class sue:
...   a = 5
...   def test(self, g):
...     t = self
...     t.a = g
...   def output(self):
...     print self.a
...
 >>> pp = sue()
 >>> pp.test(3)
 >>> pp.output()
3
 >>>


prepared-to-be-shot, -c




> 
> Maybe this is a good idea?  More likely I'm about to learn which
> critical basic flaw I've missed.
> 
> at-least-I-will-get-to-learn-something-ly yours
> 
> Andrae Muys
>