...well... how about an answer from a python hacker??
I ended up liking it a lot. When contrasted with (for example) the C
language #include directive, that brings in *tons* of stuff to
"pollute" your global name space, the idea of predictably bringing in
*exactly* one name via a "import foo" directive" is *very* clean.
With regard to using the dot notation to select items within a module,
this also ended up (IMHO) to be quite nice. Contrast it for example
with the elements of C++ that support specification within an object:
::
.
->
.*
->*
Folks in C often note that the use of "pa->b" vs "a.b" is something
that a compiler could have deduced, based on types of the first
variable , and these two constructs have such similar semantic meaning
that it is questionable as to why they were held as distinct. In C++,
the "::" operator was invented to allow specification of elements of
classes (not to be confused with members of instances :-/). Looking
at Python, it is *nice* that:
a.b(c)
*might* mean call the b method of instance a, or call the b function
in module a, or call the b method of class a explicitly using instance
c. From the *user's* (caller's) point of view, the critical thing is
that this code do what was promised. It is *nice* that the underlying
implementation can be vastly changed without changing the interface
(i.e., the syntax used by the caller).
> Also...I was also wondering about this business of "methods" having the
> same syntax as "functions" but with an extra beginning argument for self.
> Naively, I'd much rather have an argument list that matched what I was
> explicitly sending, and have "self" be a reserved word that doesn't need
> to be passed. Is it something you just get used to? Is it a
> feature?
The language that most comes to (my) mind in this regard is C++ (which
uses an implicit argument "this").... so I'll answer in that
context...
In certain ways, some of the syntax is quite helpful. Although it at
first seems like a "waste," the syntax nicely explains how to
*explicitly* call a base class method. The following example
demonstrates this:
class base:
def foo(self, a):
...
class derived:
def foo(self, a, b):
...
base.foo(self, a) # call base method explicitly
...
Hence the syntax actually makes a lot of sense when used this way
(note that the caller uses *exactly* the same signature as the
definition). In addition, *some* day Python may have what C++ defines
as static member functions, which is member functions that do *not*
take a "self" as an argument. In C++, there is the magic of the
"this" variable which appears within all member functions, but not
within any static member functions. I'd say that the present Python
syntax is a simpler, clearer, and more consistent (and learnable)
syntax than C++ (please don't get into a flame war.. I actually speak
very fluent C++, but I'm just not a fan of a number of elements of the
syntax).
I'm hopeful that the above example provides some of the justification
that I've come to see as motivations for the questioned elements of
Python.
Jim
-- Jim Roskind voice: 415.528.2546 jar@netscape.com fax: 415.528.4133 ---------------------------------------------------------------------------- PGP 2.6.2 Key fingerprint = 0E 2A B2 35 01 9B 5C 58 2D 52 05 9A 3D 9B 84 DB To get my PGP 2.6 Public Key, "finger -l jar@infoseek.com | pgp -kaf"