[Baypiggies] Frequently Argued Objections

[Chad Netzer]

On 6/23/08, Warren Stringer <warren at muse.com> wrote:
> Ok, so "var=x" instantiates a static var x, yes? For example:

Hmmm, best to put aside some of these concepts (static vars and
contructors) when thinking Pythonically; if you will indulge me:

$ python
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
>>> one = uno = 1
>>> one
1
>>> uno
1
>>> 1
1

I just created two new ways to refer to the integer 1 object.  No
copying of the 1 object occurred, just some manipulation (at runtime)
of the name table for the current scope, and some changed reference
counts.  (use locals() and globals() after the example above, to see)

As a sidenote, the 1 integer is a singleton; you can't, for example,
create another '1' valued integer with 1().  But as an instance of
type int, it has its own state (the value 1) and an interface allowing
it to be added to other integers, etc.



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


Try not to think of __init__() as a constructor (it isn't).  It is an
initializer.  :)  I'll skip the explanation for now, but feel free to
ask.

Why does it matter?  Well, Python doesn't have a "copy constructor",
for example, so that terminology can lead to some confusion.  In fact,
Python gained the __new__() method a while back, which is kinda-sorta
more like a constructor; it allows making immutable objects, for
example.  But __init__() is really much simpler than, e.g. a C++
constructor.


Now, why the explicit self?  Well, because if it were implicit, due to
Python's dynamic nature, everything would run a lot slower (if it were
even doable).  C++ has somewhat complicated rules to figure out just
what method or attribute is meant when it encounters a name in a
method call.  You can use an explicit this-> to help resolve
ambiguities.  But, in any case, that language figures it all out at
compile time.

But in Python, name lookups happen at runtime.  It is quite possible
for an object to not have a particular attribute at all until the
first time someone reads it; it could be computed each time it is
accessed, or it could involve a round trip over a network to get the
attribute value.  With an implicit self, an unqualified name in a
method call would have to probe the object for this name, thus
possibly triggering the action accidentally (what if you really meant
the global name?  You weren't explicit after all, so Python has to
look).  Or, the lookup rules would have to exclude this type of
lookup, and you would again need an explicit self in this case.
Either way, it is faster and easier to just require self.  The lookup
doesn't then depend on the dynamic nature of the language.


Now, if its a matter of typing, many programming editors have all
kinds of fancy features to help you type 'self' a lot less often.  I
can do it in Vim with abbrevations (emacs too).  TextMate on Macs
really seems to take it to the limit; see the Python video below if
you are curious:

http://macromates.com/screencasts

Other IDEs and editors have similar features;  just like whitespace
indentation, the explicit self, once you get used to it, doesn't seem
to be a big dealbreaker, IMO.

Hope this was somewhat enlightening; if was unclear, just ask.

Chad