Newbie: Functions and class

Alex Martelli aleax at aleax.it
Fri Oct 31 12:34:44 EST 2003


Shu-Hsien Sheu wrote:
   ...
> I think I can see your point. So, we can gerenally say that, only
> instances of a class can have assignments; Class name are only a
> "reference" thing and doesn't have any "exact" values bind to it. Sorry
> my wording might be wrong, but it's the best that I could think of.

No, this doesn't sound like anything having to do with Python.

Let's go back to your example.  In it, you had a function:

def <function_name_doesnt_matter_WHICH!>(<argument_name_ditto>):
    <argument_name_ditto> = [ [], [], [], [] ]

and that was all the function did.

NO MATTER WHAT the name of this function,
NO MATTER WHAT the name of its arguments,
NO MATTER WHERE the function is (inside a class statement,
    outside of it, inside another function, on a partridge tree),
NO MATTER HOW you access and call it,

*this function will NEVER, EVER do ANYTHING observable from the outside*.

It's rebinding its local variable name which is its argument's name.

That's ALL it's doing.  NOTHING ELSE, *EVER*, under ANY conditions.

Actions of a function regarding the bindings of the functions' own,
intrinsically INTERNAL, local variable names, are not per se ever
observable from the outside.

Therefore, this function's body might as well be:
    pass
under ANY conditions.

This has nothing to do with classes.  Class names can perfectly
well "have assignments" (for any reasonable readings of this "have").
Classes are objects just like any others and they're first class just
like class instances and the like.  The issue has nothing at all to
do with this.  It doesn't matter in the least that your function was
within a classbody and had the specialname __init__ and its only
argument had the conventionally-used name self -- this placement and
naming influences WHEN the function may be called, but your function
is STILL a "no-operation", totally independent of when or how it's
being called there's no way it's ever gonna DO anything.


Alex





More information about the Python-list mailing list