Newbie look at Python and OO

[Grant Edwards]

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.

My bad. Though there's mot that much difference...

--

 

[Grant Edwards]

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.

That's because those languages are all very similar in most of
the basic concepts.

Python, however, feels strange.

That's because it's different than the languages you already
knew. I might be an eye-opener to learn some other "strange"
languages: Prolog, Scheme, Smalltalk, APL, Erlang, Haskell,
Eiffel, ...

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

I still do assembly language stuff pretty regularly, and I
don't really see any similarity between Python and assembly (at
least not for the targets I work with).

 

[Steven D'Aprano]

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.

Sounds to me like it is the object-oriented stuff that causes the
confusion, not Python per se.

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

You shouldn't need to think about memory addresses in Python. The only
exceptions are that the id() function returns the memory address
(although that's just an implementation detail, it could be any old number
for all the difference it makes), and that some objects expose the memory
address as part of their default string representation:
<object object at 0xb7fb0460>

I too learnt to program in Pascal, and I also found the OO side of things
confusing at first. With the exception of a few "gotchas" like
string.join() which feels like it is written backwards, it is usually
quite natural.

You started this thread with a list of conceptual problems you were
having. Are they now cleared up?

 

[Dennis Lee Bieber]

For me, going from Pascal, to basic,c,cobol,fortran . . was not that

All those language are traditional architecture. A variable name is
tied to a physical/unchanging memory addresses, and

a = b

means "look into the box at the address of b, make a copy of the
contents, and put that copy into the box at address of a (trash anything
that had been at a)"

Even pointer variables work this way, as one must explicitly code to
dereference

a = b^ (If I recall 30 year old Pascal)

says "look into the box at address of b, use the contents as another
address, look into the box at THAT address, and copy...."

difficult. Python, however, feels strange.

Python reverses this concept. In Python, the objects themselves do
not move, but rather the addresses associated with the variable name
moves -- so an object can have multiple names associated, and assignment
moves the name without affecting the "left behind" object.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[walterbyrd]

You started this thread with a list of conceptual problems you were
having. Are they now cleared up?

Yes. Thank you, and everybody else. I'm still learning, and still
getting used to Python. But, I understand the concepts that I was
having trouble with before.