[Baypiggies] Frequently Argued Objections

[Shalabh Chaturvedi]

Resending - 1st attempt failed.

On Mon, Jun 23, 2008 at 7:31 PM, Shalabh Chaturvedi wrote:

> I don't see what ambiguity you are trying to point out. Python has a
> concept of names and objects. Also, objects have attributes that point to
> other objects. I think you are missing some simple but core concepts. See
> inline...
>
> On Mon, Jun 23, 2008 at 4:35 PM, Warren Stringer <warren at muse.com> wrote:
>
>> Ok, so "var=x" instantiates a static var x, yes? For example:
>>
>
> No, it does not instantiate anything - it just gives an object currently
> having name 'x', a new name 'var', in the current namespace. Instantiation
> is when you create an object. No new object is created by the above line.
>
>
>> 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
>>
>
> Right now you have an object called 'a', it is a class with an attribute
> 'b' (the value of a.b is already 1). You can check it at this point by
> printing a.b
>
>
>>
>> i=a()
>>
>
> Now you have created another object 'i' which is an instance of the
> original 'a' (i.__class__ is a). The new object 'i' also has an attribute
> 'b' - value of i.b is 2 because you set it in __init__. i.b is not the same
> as a.b - 'i' and 'a' are two different objects, each with an attribute
> called 'b'. The self inside __init__ was just another temporary name for the
> object now knows as 'i'. Same object, two names. Self is a local name - that
> name no longer exists once you exit __init__().
>
> i.f() # => prints 1 2 3
>>
>
> You're printing a.b, i.b and the local 'b' that only exists within f().
>
>
>> a.b=4
>> i.f() # => prints 4 2 3
>> j=a()
>>
>
> Now you have created another object 'j' different from 'i', but similar
> because j.__class__ is also '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
>>
>
> Doesn't this above line print 5 2 3?
>
>  So, the ambiguity is that
>>
>>     whatever=a() will instantiate b=1 once, whereas
>>
>
> No whatever=a() doesn't 'instantiate' b=1 at all. a.b=1 is already set
> before you execute this line. And i.b=2 is set within the __init__()
> function (within that function the new object has a different name - self).
>
>     whatever.f() will instantiate b=3 always
>>
>
> f() contains a local variable 'b', this has nothing at all to do with
> either the instance (i or j) or the class (a). Except that f() happens to be
> a method in class a.
>
>
>> Must keep track that
>>     a.b behaves differently from i.b, since
>>     i.b=6 implicitly passes self,
>>
>
> It doesn't implicitly pass anything. It just sets the attribute 'b' of
> object 'i' to 6. When you call i.f() - that implicitly passes i as the first
> argument - it is equivalent to calling f(i) - or rather  a.f(i).
>
>
>>         somewhat akin to i.self.b, tho not quite
>>          (how would one express as internal dictionaries?)
>>
>
> There is no i.self. But self is sometimes a function local name for i, at
> other times it's a function local name for j. Same object, different names
> in different places.
>
>
>> 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
>>
>>
>>
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> http://mail.python.org/mailman/listinfo/baypiggies
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20080623/5a61cacc/attachment.htm>