Newbie look at Python and OO

[Chris Mellon]

On 10 May 2007 08:58:54 -0700, walterbyrd <walterbyrd at iname.com> wrote:
> I learned to program with Pascal, way back when. Went into software
> development for a while, then went into systems admin. Have programmed
> in several languages, just learning Python.
>
> Some things I find odd:
>
> 1) 5/-2 == -3?
>

Integer division. A gotcha, I grant you. Fixable with a __future__
import which will become the default soonish.

> 2) list assignment handling, pointing two vars to the same list:
>
> With simple data types:
> >>> a = 5
> >>> b = a
> >>> a = 3
> >>> a,b
> (3, 5)
>
> Which is what I'd expect, since I have changed a, but not b.
>
> But with lists:
> >>> a = list("1234")
> >>> b = a
> >>> a.append("5")
> >>> a,b
> (['1', '2', '3', '4', '5'], ['1', '2', '3', '4', '5'])
>
> b  changes even though I have not touched b. I know why, but this is
> not what I would ordinarilly expect, it does not seem intuitive. And,
> IMO, it gets worse:
>

I don't like the word "intuitive", because it's meaningless. Something
intuitive is something that you already know. You're taking a model of
variables and references from another language, and assuming Python
works the same way when it doesn't.

There's no good reason to assume this, and it's well documented that
you shouldn't. The problem comes when people try to teach Python by
telling you it's "pass by reference" or "it's like a pointer" - it's
not, and you need to be taught how it *actually* works, which isn't
especially complicated (easier to grasp than pointers, in my
experience).

> >>> a = list("1234")
> >>> b = a
> >>> a = a + ['5']
> >>> a,b
> (['1', '2', '3', '4', '5'], ['1', '2', '3', '4'])
>
> Sometimes changing a changes b, and sometimes not. You also have to
> remember that subseqent changes to a will not change b - after some
> operation but not others. To those who think in Python, I'm sure this
> all seems normal. But, having programmed in about one dozen other
> language, this seems downright bizare to me. I know why it works like
> this, but it seems like an odd way to do things.
>

You have to disabuse yourself of the idea that assignment and
"changing" are the same thing. People without previous programming
experience rarely stumble on this particular hurdle.

> 3) ambiguous use of the form: this.that()
>
> Sometimes, this.that() means module.funcion() as in:
>
> >>> os.dirlist(".")
>
> Other times, "this" is sort of like a parameter to the "that"
> function:
>

this.that() is *always* looking up "that" in "this" and calling it. It
never does anything else.
What "that" you get depends on what "this" is, and I don't know how
you could ever expect anything else.

> >>> a = list("1234")
> >>> "_".join(a)
> '1_2_3_4_5'
>
> And still other times, is seems that "this" is an object, acted upon
> by "that" :
>
> >>> a = list("1234")
> >>> b = "_".join(a)
> >>> b.split("_")
> ['1', '2', '3', '4', '5']
>
> BTW: it seems a bit odd to that the positions of the string, and the
> delimitor, are reversed between the complementory functions join(),
> and split(). I suppose if it weren't for OO, we have something
> terribly complicated, like:
>
> split(str, "_")
> join(str, "_")
>

Join takes a iterable, not a string. It's "reversed" from what you
might expect so that it can generically work over any sort of sequence
or iterable.

> Again, those who think in Python, will understand right away that:
>
> math.count(x)
>
> is counting the substring "x" in the "math" string. But can you see
> where that might be confused to be a function called count() in the
> math module?
>

This is a good reason not to give a variable which contains a string a
name like "math". The language can't protect you from this, and how
would you expect it to?

Obviously, especially as the standard lib grows, it can be difficult
to avoid these sorts of name collisions. But context is everything and
in well written code it shouldn't be hard to disambiguate these sort
of things.

> I'm not complaining. Python is a great language in many respects. But,
> I would take some issue with those claiming Python is intuitive and
> easy. IMO: there seems to be many ambiguous, unintuitve, and
> confusing, aspects to Python.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>