Do I always have to write "self." ?

Dave Abrahams abrahams at
Mon May 1 20:59:55 EDT 2000

in article slrn8gqf3a.k65.kc5tja at, Samuel A. Falvo II at
kc5tja at wrote on 4/30/00 8:19 PM:

> If an object exposes a particular interface, then it is guaranteed to be of
> a particular type.


type({}) is types.DictType
type(UserDict()) is types.InstanceType

> Defining parameters in terms of their roles is
> analogous.  Again, I just don't see the distinction.

Well, if you're writing a function to match the list of dogs waiting for
adoption at a stray dog shelter with a list of potential owners, you write

    def match_up(seqOfPeople, seqOfDogs): # named in terms of interface
        for person in seqOfPeople:
            for dog in seqOfDogs:

(or something), and I write

    def match_up(potential_owners, available_animals): named by role
        for owner in potential_owners:
            for adoptee in available_animals:

> Finally, yes, Hungarian is best used only selectively.  I strongly dislike
> redundant information source code.  For example:
> def PrintName( name ):
>    print "The name is %s" % name
> .
> .
> .
> for listOfNames in listOfListOfNames:
>   for name in listOfNames:
>      PrintName( name )
> Note that I do NOT use Hungarian inside of PrintName(), because it would be
> completely redundant.  Within the context of the function, the type of a
> name would obviously have to be a string.

It ain't obvious to me.

class Foo:
    def __str__(self):
        return "***"

>>> PrintName( Foo() )
The name is ***

> But outside the function, where the context could be *anything*, I use
> Hungarian notation to make it patently obvious the types of data I'm dealing
> with.
> Some might say, "listOfListOfNames" isn't Hungarian notation.  Isn't it?
> Isn't Hungarian notation just a consistent system by which you tag variable
> names with the intended datatypes of the objects they hold/refer to?

You can change the meaning of "Hungarian" all you want, adapt it to your own
purposes, whatever, as far as I'm concerned (Hungarians might feel
differently, though ;))

Still if your listOfListOfNames represents a way to map latitude and
longitude to the names of cities, then "cityNames" or
"mapCoordinateCityName" might be a better name for it.

> If we
> chose to use an abbreviation, we'd get llNames, which is decidedly closer to
> what Microsoft uses in their software.

You say that like it's a *good* thing ;)

> This technique is not new, nor was it "invented" at Microsoft either.
> Mathematicians have often used the "Factor Label" method for solving
> equations for eons.  There's a whole algebra of working with units.  For
> example, if you're going X miles/hour, and you've been travelling for Y
> hours, then the distance you've travelled is Z=(X*Y) miles.  Or:
> distanceZ = speedX * timeY
> Why can't this be applied to computer programming too?  Given a pointer to a
> pointer to an object,
> pObject = *ppObject;    /* The * operator cancels out a p */
> or:
> pArgument = argv[2];
And where's the unit cancellation here?

The analogy doesn't carry too well here.

In physics, you can only add objects with identical units, but you can add
an integral type to a pointer in 'C'. Can you cancel types in 'C' when you

I don't think you're being fair to mathematicians and physicists by trying
to saddle them with responsibility for this nastiness.

> Oh, here's a beautiful example of 'reverse' Hungarian notation, which
> someone else on this newsgroup recommended/inquired about:
> void main( int argc, char *argv[] );
> ^          ^

I'm afraid to ask...


More information about the Python-list mailing list