Newbie look at Python and OO

[Neil Cerutti]

On 2007-05-10, 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?

Any math implementation has to decide on the convention for
division of negative numbers (which most people think they
understand) so that it works logically with the implementation of
the mod operator (which most people don't clame to understand for
negative numbers).

C says something complicated to allow differing yet compliant
answers, while Python defines it strictly for programmer
convenience.

> 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:

Actually, binding to numbers works just the same as for lists,
it's just that you can't change a number, it is immutable. You
just end up rebinding to a new number object.

 >>> a = 3

Now a is bound to a number object representing 3.

 >>> b = a

b and a are now both bound to the same number object.

 >>> id(b) == id(a)
 True

A number object cannot be modified, unlike a list.

 >>> a += 5

A is in fact rebound to a new number object representing 8 by the
above line.

 >>> id(a) == id(b)
 False

>>>> 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. 

The + operator does not change a list, it produces a new one.

> 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:

It's the exact same operation each time (attribute lookup), it's
just that it's operating on two different object types.

> 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 is a tiny sore spot for some Python users, I think. No
language is perfect. ;)

> 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?

The only thing you know for sure (without tracing backwards) is
that count is an attribute of the object bound to the name 'math'
(or something masquerading as an attribute. Look under the hood
at descriptors for the details).

> 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.

Name binding can seem confusing at first, but it's really the
distinction between mutable and immutable objects that's the root
of your current confusion.

-- 
Neil Cerutti