[Baypiggies] Frequently Argued Objections

[Warren Stringer]

Hey JJ, Kelly, I've combined both of your replies,

On Jun 23, 2008, at 2:48 AM, Shannon -jj Behrens wrote:

> Let's make it really fun:
>
> from thirdparty import *
>
> class A(B):
>  def bar():  # Assuming we have implicit self.
>    foo()
>
> Now, did foo come from:
>
> * The parent class B?
> * Something in thirdparty?
> * Something in thirdparty that someone else shoved in there  
> dynamically?
> * Something in builtins that someone else shoved in there dynamically?
> * Some global in the current module that's a few hundred lines down?
> * Some global in the current module that someone else shoved in from
> a third-party module? ;)
>
> Using self cuts down on the possibilities which:
>
> a) Saves the interpreter from doing a bunch of useless dict lookups.
> b) Saves the reader from trying to figure out what's going on.

OK, I'm sure that I'm missing something. Couldn't this be resolved  
with something like:

1) B.foo()
2) super.foo() # or ..foo() with dot_as_self convention expanded to  
emulate a file system
3) thirdparty.foo()
4) __builtins__.foo(

Moreover, since we're talking about not using self for items that are  
local to the class, the example should really be:

class A(B):
   def foo:
      ... # foo statements
   ...  # other statements
   def bar():
       foo()

In this case, the resolving of 'foo' ranges from blindingly easy (when  
the distance from foo's declaration is short), to search-ably easy  
(when the distance from foo's declaration is long)

On Jun 22, 2008, at 11:53 PM, Kelly Yancey wrote:
>
>  I admit, I have had to call self by another name on a couple of  
> occasions.  Specifically, I had a factory method in one class that  
> returned instances of a dynamically-created class.  The returned  
> objects had methods that referenced both their own instance's  
> attributes and attributes of the factory method's parent object (via  
> closure).  Since there were two objects involved, I used self to  
> refer to the factory-generated object itself, and had the factory  
> method use a different name for its own object reference argument so  
> the generated object could still access both.
>  Complicated?  Sure.
>  Possible with implicit self?  Nope


As with other languages, 'self' can still be available; simply not  
required.

On Jun 23, 2008, at 2:48 AM, Shannon -jj Behrens wrote:
> As a blanket statement, polymorphism can be confusing.  When I see
> "self", at least it's a good sign that I should start looking at
> either the class's documentation or one of its ancestor's
> documentation.
>
> -jj

These days, I do a search within the IDE, a spotlight search (Mac), or  
a Google Desktop search (PC). WIth several IDEs, I can right click to  
find the definitions. Some tools provide an accurate call graph. Many  
of these tools weren't available when Python was first created. Thirty- 
three years ago, most of my debugging involved reading code printouts  
from a KSR 35 teletype. Since then, my habits have changed.

My guess is that:
	1)  9 times out of 10 the var in self.var is blindingly obvious,
	2) 99 times out of 100 it is obvious after a 10 second search,
	3) when non-obvious, it may indicate an obscure namespace that
  		a) has ballooned out to a complexity that should be refactored
		b) wouldn't be solved by simple code reading aides, like self

\~/