[Baypiggies] Frequently Argued Objections

[Warren Stringer]

Ok, so "var=x" instantiates a static var x, yes? For example:

class a(object):
     b=1
     # self.b does not work here
     def __init__(self):
         self.b=2 # so declare it in the constructor
     def f(self):
         b=3
         print a.b, self.b, b
         b=b+1

i=a()
i.f() # => prints 1 2 3
a.b=4
i.f() # => prints 4 2 3
j=a()
j.f() # => prints 4 2 3
a.b=5 # will change for i and j
i.f() # => prints 5 2 3
j.f() # => prints 5 2 3
i.b=6 #changes self.b
i.f() # => prints 5 6 3
j.f() # = prints 2 6 3

So, the ambiguity is that
     whatever=a() will instantiate b=1 once, whereas
     whatever.f() will instantiate b=3 always

Must keep track that
     a.b behaves differently from i.b, since
     i.b=6 implicitly passes self,
         somewhat akin to i.self.b, tho not quite
         	(how would one express as internal dictionaries?)

As stated about @var, in Ruby:  "but conceptually bends Occam's razor  
-- it makes the language introduce one more rule"
One may make the case that examples for b=1, b=3, a.b=5, i.b=6 also  
introduce more rules.

This is what confused me the most, when learning Python. I have heard  
similar objections. I have seen plenty of questions posted about this  
problem and have seen many replies posted that essentially say "oh no,  
not THAT question again."

There are several methods of dealing with objections:
	1) ignore it by calling it whining
		a) and hope the whiners go away
	2) acknowledge the problem
		a) show how it solves a bigger problem
		b) show how a fix would create new problems
	3) eliminate the source of the problem
		a) without creating new problems

Guess which methods increase the popularity/longevity of a product?  
Since 3) is not going to happen for self, I would suggest 2) over 1).

\~/

On Jun 23, 2008, at 8:40 AM, Alex Martelli wrote:

> On Mon, Jun 23, 2008 at 7:41 AM, Warren Stringer <warren at muse.com>  
> wrote:
>   ...
>> 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,
>
> I think that there are way more than 1 in 100 uses even just for the
> simplest example that shows this guess to be unfounded: "self.var = x"
> which would allowed to become "var = x"  under a deleterious "implicit
> self" rule.
>
> Right now, "var = x" sets a local variable in the method, "self.var =
> x" sets an instance variable: zero ambiguity, zero chances for error,
> zero problems -- well let's say epsilon problems rather than zero,
> because there IS the issue of having to listen to whines against
> "mandatory explicit self";-).
>
> There are good ways and bad ways to address this issue during language
> design. The best way -- as in Modula-3, Python, Perl-5, Ruby -- is to
> explicitly mark instance variables (self.var in Modula-3 and Python,
> $self->{var} in Perl-5, @self in Ruby); a somewhat inferior way -- as
> in Squeak -- is to give up some of the language's dynamic nature by
> forcing variables to be declared; a worse way would be to break
> symmetry by using the explicit mark in assignment but not in
> reference.
>
> The very worst way is shown by Javascript's "with" statement -- within
> a Javascript "with zap", the meaning of "zop = 23" is essentially
> unguessable as it depends on whether zap already did have a zop
> attribute (in which case it rebinds it) or not (in which case it binds
> a global variable -- unless there was an earlier declaration of "var
> zop" in this function, in which case it binds the local variable
> instead) -- a mix of forced declaration and blind guessing that good
> books on Javascript (e.g. the short and useful "Javascript, the good
> parts") strive to convince the reader to never, ever use that accursed
> statement.
>
> Within the "explicit mark" camp, Ruby's "@var" is typographically
> concise but conceptually bends Occam's razor -- it makes the language
> introduce one more rule (on the meaning of a "@" prefix) where the
> choice that Python took from Modula-3 just reuses an existing rule
> (whatever.var means exactly the same in all cases, whether "whatever"
> is "self" or something other than "self" -- no special cases, no extra
> rules).
>
>
> Alex
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20080623/25a37869/attachment.htm>