On May 10, 2:21 pm, [EMAIL PROTECTED] wrote:
> walterbyrd 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?
>
> > 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:
>
> > >>> 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.
>
> > 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:
>
> > >>> 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, "_")
>
> > 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?
>
> > 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.
>
> These conversations are funny to me. I use Python every day and I
> have never actually thought about the implications of binding objects
> to names, or two names pointing to the same object. Problems of this
> sort just never come up in actual programming for me. It just works.
>
> Python was my virgin language, so maybe that just makes it natural to
> me, but it seems like people coming from other languages get hung up
> on testing out the differences and theories rather than just
> programming in it. Alas, maybe I have yet to get deep enough to run
> into these kinds of problems.
>
> The question of what math is in math.count(x) makes sense, but this
> one never comes up either (or rarely). I usually know what the object
> is that I'm working with.
>
> ~Sean
After thought:
I do run into problems testing boolean values on a regular basis.
Probably should learn all the rules on them and use them properly, but
as a general rule I just don't use them, and test for the value
instead.
~Sean
--
http://mail.python.org/mailman/listinfo/python-list
