Newbie look at Python and OO

[walterbyrd]

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 types3, 5)

Which is what I'd expect, since I have changed a, but not b.

But with lists['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:

Other times, "this" is sort of like a parameter to the "that"
function:
'1_2_3_4_5'

And still other times, is seems that "this" is an object, acted upon
by "that" :
['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.

 

[Grant Edwards]

2) list assignment handling, pointing two vars to the same list:

Python doesn't have variables. It has objects to which you can
bind names.

But with lists:

That creates a list object and binds the name "a" to it.

That binds the name b to that same object.

You now have two names bound a single object.

Now you modify that object.

(['1', '2', '3', '4', '5'], ['1', '2', '3', '4', '5'])

b changes even though I have not touched b.

You modified the object to which the name "b" is bound.

I know why, but this is not what I would ordinarilly expect,

Stop thinking in "C".

it does not seem intuitive.

When one attempts to use intuition devloped in one environment
in a different environment it is often wrong. That's why
brains have capability to change.

And,
IMO, it gets worse:

Again, you have a single object to which both names "a" and "b"
are bound.

a = a + ['5']

Now you've created a new object and bound the name "a" to it.
You now have two objects and the name "b" is still bound to the
original one.

(['1', '2', '3', '4', '5'], ['1', '2', '3', '4'])

Sometimes changing a changes b, and sometimes not.

You're thinking wrongly. Start thinking about objects/names
and not about "variables".

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.

Yes, it does.

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.

If those dozen other languages all used the "variable" paradigm
(fixed regions of storage with fixed names) rather than the
object/name binding paradigm, then yes, it probably seems like
an odd way to do things.

If you grew up using base-12, then base-10 seems like an odd
way to do things.

3) ambiguous use of the form: this.that()

Nope, it always means exactly the same thing: look up the
"that" attribute of object "this", and then call it. Are you
confused by the fact that modules are objects?

Sometimes, this.that() means module.funcion() as in:

Call the "dirlist" attribute of the object to which the name
"os" is bound.

Other times, "this" is sort of like a parameter to the "that"
function:

'1_2_3_4_5'

Call the "join" attribute of the anonymous string object
"_".

And still other times, is seems that "this" is an object, acted upon
by "that" :
['1', '2', '3', '4', '5']

Call the "split" attribute of the object to which the name "b"
is bound.

Again, those who think in Python, will understand right away that:

math.count(x)

is counting the substring "x" in the "math" string.

No, that isn't obvious at all unless we've previously been told
that the name "math" is bound to a string object and we happen
to know that a string object's "count" attribute is a bound
method that counts occurances of the passed substring.

But can you see where that might be confused to be a function
called count() in the math module?

A python programmer would think that it's calling the "count"
attribute of whatever the name "math" is bound to. The name
"math" might be bound to a module, a string, or some other type
of object.

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.

Unlearning old habits is always difficult.

IMO: there seems to be many ambiguous, unintuitve, and
confusing, aspects to Python.

Certainly if you're thinking about it using the wrong set of
concepts.

 

[Carsten Haese]

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?

Division of integers performs a "floor division" that rounds the result
down to a whole number. If you want a floating point result, you'll need
to specify that you're working with floats: 5.0/-2 or float(5)/-2

2) list assignment handling, pointing two vars to the same list:

See http://effbot.org/zone/python-objects.htm .

3) ambiguous use of the form: this.that()

The form "this.that" *always* means the same: It refers to the attribute
called "that" of the object called "this". This may yield seemingly
different meanings depending on what type of object "this" is, but the
basic mechanism is always the same.

The main source of your confusion seems to stem from the fact that
join() was decided somewhat non-intuitively to be a method of string
instances.

By the way, the next time you have a number of unrelated questions,
please consider posting them in separate messages. That allows you to
pick a more descriptive subject line for each message, and it makes the
ensuing conversations easier to follow.

Best regards,

 

[Chris Mellon]

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 types3, 5)

Which is what I'd expect, since I have changed a, but not b.

But with lists['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:


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.

'1_2_3_4_5'

And still other times, is seems that "this" is an object, acted upon
by "that" :
['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.

 

[Larry Bates]

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 types3, 5)

Which is what I'd expect, since I have changed a, but not b.

But with lists['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:

Other times, "this" is sort of like a parameter to the "that"
function:
'1_2_3_4_5'

And still other times, is seems that "this" is an object, acted upon
by "that" :
['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.

Some of your confusion is because you have ingrained ideas about how
"other" languages handle things and want Python to do it the same way.
Give it some time and you will begin to understand (as many have) that
there REALLY is method to the apparent madness...

Some things I find odd:

1) 5/-2 == -3?

What do you except from integer arithmetic? The ONLY possible
answers are -2, or -3. Python chooses to always return the floor
(lower) of the two values in integer division. While this makes
complete sense for positive integers, it seems odd for negative
ones, but it is consistent.

With simple data types:
(3, 5)

Here you confuse Python's complete object orientation with other
previously learned languages.

a=5

In python means: make me a name 'a' in the local namespace that points
to an object that holds a 5. It does not mean: create a memory
area referred to by a and place a 5 in it (as many other languages
do).

b=a

In python means: make me a name 'b' in the local namespace that points
to object 'a'.

A good way to see this is to do:

id(a)
id(b)

you will see that they both point to the same object.

Which is what I'd expect, since I have changed a, but not b.

But with lists['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:

Again this is because of objects not "containers" like Pascal or other
languages.

b=a

In python means: create me an object 'b' that points the same place as
object 'a'.

a.append("5") modifies both variables because both variables point to
the same place.

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.

do 18192784

a=a+['5']

In python means: create a new object a that is the old object a with
a '5' appended to the list.

Now look at the ids of the two variables:
18192784

See 'a' and 'b' now point to different places. Append does in-place
append, the a+['5'] makes a new object.

3) ambiguous use of the form: this.that()

Sometimes, this.that() means module.funcion() as in:


Other times, "this" is sort of like a parameter to the "that"
function:

this.that() syntax always calls the that method of the object this.

'1_2_3_4_5'

"_" is a string object that has all the methods any other string object
will have. Objects don't have to be named (via variables) to have
methods.

You could write:

underline="_"
underline.join(a)

And still other times, is seems that "this" is an object, acted upon
by "that" :
['1', '2', '3', '4', '5']

Not really, you can write:

underline="_"
b=underline.join(a)
c=b.split(underline)

seems perfectly clear to me (but I have to admit it took me a while
to see the beauty of python's syntax).

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?

Actually it could be either. If you write your own class called math
that has a count method this would work. If the math module had a
count method (which it doesn't) and you import it, you might call that
method of the math module this way. One thing you will come to
appreciate is that you can replace virtually any module, function,
etc. in Python with your own code. A mistake many new python programmers
make is to shadow str, list, dict, etc. by using them as variable names.
Then later they can't figure out why they can't do str(n).

Hope the feedback helps.

-Larry

 

[jmg3000]

[snip]

2) list assignment handling, pointing two vars to the same list:

With simple data types:>>> a = 5
(3, 5)

Which is what I'd expect, since I have changed a, but not b.

But with lists:>>> a = list("1234")
(['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.

Well, although it may not be what you expect right now, it *is* quite
uniform with the rest of the language. That is: labels refer to
objects. Writing ``a = b`` just makes the 'b' label refer to the same
thing that the 'a' label refers to. Nice and simple.

And,
IMO, it gets worse:

a = list("1234")
b = a
a = a + ['5']
a,b

(['1', '2', '3', '4', '5'], ['1', '2', '3', '4'])

Now here, after you've set 'a' and 'b' to refer to the same object,
you went and created a new object (a + ['5']) for a to refer to. ``a +
['5']`` creates a new object, whereas ``a.append('5')`` just modifies
the existing object. (By the way, as an aside, '5' is a one-character
string, not a number.)

[snip]

3) ambiguous use of the form: this.that()

Sometimes, this.that() means module.funcion() as in:

Other times, "this" is sort of like a parameter to the "that"
function:

'1_2_3_4_5'

I think I see what you mean: In Python, there's this convention that
you're supposed to name your classes starting with a capital letter
(``class HeadCheese(object):``), but for core built-in classes, they
start with a lower-case letter (like ``list``, ``dict``, ``set``,
``file``, etc.). So, ``list('foo')`` is actually a constructor call.

Also, note that, in Python, "_" is a literal for creating a string
object, so you can call methods on that resulting object -- as in
``'_'.join('cheezit')`` -- the same as if you'd said ``foo = "_";
foo.join('cheezit')``.

[snip]

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.

Well, every language has its warts. Folks are working to minimize
or remove a number of them for Python 3000.

---John

 

[Neil Cerutti]

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 types3, 5)

Which is what I'd expect, since I have changed a, but not b.

But with lists['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.

Now a is bound to a number object representing 3.

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

A number object cannot be modified, unlike a list.

A is in fact rebound to a new number object representing 8 by the
above line.
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:


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.

 

[walterbyrd]

Thanx for all the replies, I may be slowly getting it. But, can
anybody explain this?
False

 

[walterbyrd]

Nevermind my previous question. I found the answer in "Learning
Python"
Python internally caches and reuses short strings as an optimization,
there really is just a single string, 'spam', in memory, shared by S1
and S2; hence, the is identity test reports a true result. To trigger
the normal behavior, we need to use longer strings that fall outside
the cache mechanism:
<<

 

[Bruno Desthuilliers]

walterbyrd a écrit :

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.

2) list assignment handling, pointing two vars to the same list:

With simple data types:

(3, 5)

Which is what I'd expect, since I have changed a, but not b.
s/changed/rebound/

But with lists:

(['1', '2', '3', '4', '5'], ['1', '2', '3', '4', '5'])

b changes even though I have not touched b.

You did call a mutating method on the object pointed by both a and b.
You're comparing apples and oranges here. The second snippet should be:

>>> a = [1, 2, 3]
>>> b = a
>>> a = [4, 5, 6]
>>> a, b ([4, 5, 6], [1, 2, 3])
>>>

I know why, but this is
not what I would ordinarilly expect, it does not seem intuitive.

If so your intuition is based on misconceptions. In Python, a 'variable'
is really a name=>object_ref pair in a namespace (think of namespaces as
dicts). The name by itself is only that : a name. The "value" is
*always* a reference to an object, and a same object can be referred to
by many names. In Pascal terms, this is similar to (smart) pointers to
records.

And,
IMO, it gets worse:

a = list("1234")
b = a
a = a + ['5']

Here you're rebinding the name 'a' to a new list object which is the
concatenation of the list object previously bound to 'a' and the
(anonymous) ['5'] list object.

(['1', '2', '3', '4', '5'], ['1', '2', '3', '4'])

Sometimes changing a changes b, and sometimes not.

Rebinding a name doesn't affect the object previously bound to it.
Changing the state of an object of course affects the object.

You also have to
remember that subseqent changes to a will not change b - after some
operation but not others.

Binding and method calls are quite distinct operations.

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.

This is obvious when stop thinking in term of "boxes" (ie: a variable is
a box containing a value) and start thinking in terms of references.

3) ambiguous use of the form: this.that()

Sometimes, this.that() means module.funcion() as in:


Other times, "this" is sort of like a parameter to the "that"
function:


'1_2_3_4_5'

And still other times, is seems that "this" is an object, acted upon
by "that" :


['1', '2', '3', '4', '5']

In *all* cases, 'this' is an object, and 'that' is an attribute of
'this'. This is definitively not ambiguous. You have to understand that
everything in Python is an object - including functions, classes and
modules.

os.listdir : this is the (function object) attribute 'listdir' of module
object os
"_".join : this is the (method object) attribute 'join' of class str:
b.split: this is the (method object) attribute 'split' of class str.

In these three examples, these attributes are callable objects, and you
apply the call operator to them.

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

Yes, it's a bit surprising at first. But it's still logical.
some_string.split(delimiter) => new_list
delimiter.join(some_list) => new_string

I suppose if it weren't for OO, we have something
terribly complicated, like:

split(str, "_")
join(str, "_")

This should be:
join(list, "_")

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?

No, I can't. Because
1/ my functions (or methods) are too short for such a confusion to be
possible
2/ I wouldn't name a string "math"

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.

I guess this has to do with your (very procedural) background. Of
course, Python does have it's share of gotchas and warts, but it's one
of the only languages I know that you can start to be productive with in
a matter of days.

 

[half.italian]

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 types3, 5)

Which is what I'd expect, since I have changed a, but not b.

But with lists['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:

Other times, "this" is sort of like a parameter to the "that"
function:
'1_2_3_4_5'

And still other times, is seems that "this" is an object, acted upon
by "that" :
['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

 

[half.italian]

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

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

 

[Bruno Desthuilliers]

walterbyrd a écrit :

Thanx for all the replies, I may be slowly getting it. But, can
anybody explain this?



False

Python - well, CPython (the reference C implementation) at least - tries
to optimize memory usage by "interning" (caching/reusing) string objects
when possible. You'll find a similar behaviour with integers:
IOW, this is an implementation detail. FWIW, you should not use identity
tests on immutable objects (the None object set aside) - since they are
immutable, equality test is enough.

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :
(snip)

After thought:

I do run into problems testing boolean values on a regular basis.

FWIW, booleans were a late add-on. Originally, Python didn't had a bool
type, only rules about the boolean value of a given object, mostly: 0,
0.0, '', [], (,), {} and None are false (you'll probably notice a
pattern with a concept of emptyness). These rules still apply of course.

 

[Gabriel Genellina]

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.

Certainly, learning Python as a first language has some advantages. But I
think you'd feel a bit shocked if you had to program in C++ someday; these
rather innocent lines might not do what you think:

a = 0;
b = a;

From a C++ point of view, it would be natural that:
- a is not 0, and it might not even be a number.
- (a==0) may be false, and (b==0) too.
- b is not the same thing as a, may be a totally different type, and if it
were something like Python's "mutable containers", mutating b would have
no effect on a.

Simple things have so complex and ugly rules that... ugh, enough for now.
But people coming from other languages/backgrounds may think Python syntax
a bit strange at first - just for a while, but if they can pass the "Gimme
my curly braces back!" stage, most end loving Python.

 

[Grant Edwards]

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.

Certainly, learning Python as a first language has some
advantages. But I think you'd feel a bit shocked if you had to
program in C++ someday; these rather innocent lines might not
do what you think: [...]
Simple things have so complex and ugly rules that... ugh, enough for now.

http://www.ariel.com.au/jokes/An_Interview_with_Bjarne_Stroustrup.html

Maybe BS thought he was joking, but IMO, it's true.

"Stroustrup: Remember the length of the average-sized 'C'
project? About 6 months. Not nearly long enough for a guy
with a wife and kids to earn enough to have a decent
standard of living. Take the same project, design it in C++
and what do you get? I'll tell you. One to two years."

 

[Duncan Booth]

http://www.ariel.com.au/jokes/An_Interview_with_Bjarne_Stroustrup.html

Maybe BS thought he was joking, but IMO, it's true.

"Stroustrup: Remember the length of the average-sized 'C'
project? About 6 months. Not nearly long enough for a guy
with a wife and kids to earn enough to have a decent
standard of living. Take the same project, design it in C++
and what do you get? I'll tell you. One to two years."

I doubt very much that BS was involved at any point in writing it. You
forgot to quote the bit at the end:

[Note - for the humor-impaired, not a true story]

 

[Grant Edwards]

http://www.ariel.com.au/jokes/An_Interview_with_Bjarne_Stroustrup.html

Maybe BS thought he was joking, but IMO, it's true.

"Stroustrup: Remember the length of the average-sized 'C'
project? About 6 months. Not nearly long enough for a guy
with a wife and kids to earn enough to have a decent
standard of living. Take the same project, design it in C++
and what do you get? I'll tell you. One to two years."

I doubt very much that BS was involved at any point in writing it. You
forgot to quote the bit at the end:

[Note - for the humor-impaired, not a true story]

My bad. I completely missed that -- I thought it was a real
interview where BS was joking.

 

[Steven D'Aprano]

Stop thinking in "C".

Dude! Did you miss the Original Poster's VERY FIRST SENTENCE???

"I learned to program with Pascal, way back when."

He's thinking in Pascal, not C.

 

[walterbyrd]

He's thinking in Pascal, not C.
Actually, I have programmed in many languages. I just first learned in
Pascal.

For me, going from Pascal, to basic,c,cobol,fortran . . was not that
difficult. Python, however, feels strange.

As crazy as this may sound: Python, in some ways, reminds me of
assembly language. I haven' t programmed in assembly in a *long* time.
But I vaugly remember doing a lot of stuff where I used memory
addresses as pointers to data, and also as pointers to pointers.
Although, when I first started assembly language, I think it took me a
week to write a program to print "hello world."