OO in Python? ^^

[Matthias Kaeppler]

Hi,

sorry for my ignorance, but after reading the Python tutorial on
python.org, I'm sort of, well surprised about the lack of OOP
capabilities in python. Honestly, I don't even see the point at all of
how OO actually works in Python.

For one, is there any good reason why I should ever inherit from a
class? ^^ There is no functionality to check if a subclass correctly
implements an inherited interface and polymorphism seems to be missing
in Python as well. I kind of can't imagine in which circumstances
inheritance in Python helps. For example:

class Base:
def foo(self): # I'd like to say that children must implement foo
pass

class Child(Base):
pass # works

Does inheritance in Python boil down to a mere code sharing?

And how do I formulate polymorphism in Python? Example:

class D1(Base):
def foo(self):
print "D1"

class D2(Base):
def foo(self):
print "D2"

obj = Base() # I want a base class reference which is polymorphic
if (<need D1>):
obj = D1()
else:
obj = D2()

I could as well leave the whole inheritance stuff out and the program
would still work (?).

Please give me hope that Python is still worth learning :-/

Regards,
Matthias

[Fredrik Lundh]

Matthias Kaeppler wrote:

I really see issues with this, can anyone comment on this who has been
working with Python more than just a day (like me)?

Maybe you should work with Python more than one day before you
start looking for potential problems? ;-)

(I suggest reimplementing some portion of some C++ program you've
worked on recently, to get a feel for the language.)

For any potential problem you can think of, you'll find people here
who've never ever had any problems with it, and you'll find people
who think that this specific problem is what prevents Python from
going "mainstream " (and who love when someone else seems to
support their view, whether they really do it or not).

FWIW, having worked full time in and on Python for over 10 years, I
can assure you that I don't have a problem with:

- mistyped variable names
- indentation ("SUCKS BIG TIME")
- how to handle import statements
- finding things in the library reference
- the blue color on python.org
- the size of the python DLL on windows
- tabs vs. spaces
- unnecessary colons
- lambdas being removed in python 3.0
- lambdas not being removed in python 3.0
- limited support for GIF animation in PIL
- the noise level on comp.lang.pytho n
- the global interpreter lock
- the unsuitability of notepad as a programmer editor
- the number of web frameworks available

or any of the other "major" problems that you'll hear about on c.l.python
from time to time. But that's me. Your milage may vary. The only way
to find out is to use the language. Write code, not usenet posts.

</F>

[Aahz]

In article <dn************ *@news.t-online.com>,
Matthias Kaeppler <"matthias at finitestate dot org"> wrote:

Another thing which is really bugging me about this whole dynamically
typing thing is that it seems very error prone to me:

foo = "some string!"

# ...

if (something_fuba r):
fo = "another string"

Oops, the last 'o' slipped, now we have a different object and the
interpreter will happily continue executing the flawed program.

pychecker (or pylint, but I haven't tried that)
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

"Don't listen to schmucks on USENET when making legal decisions. Hire
yourself a competent schmuck." --USENET schmuck (aka Robert Kern)

[Steven D'Aprano]

On Sun, 11 Dec 2005 05:48:00 -0800, bonono wrote:

Steven D'Aprano wrote:

Python works well with test-driven development. Test-driven development
will pick up this sort of error, and many other errors too, with less
effort and more certainty than compile-time checking. The problem with
static typed languages is that they make the programmer do a lot of the
work, just so the compiler can pick up a few extra errors at compile time
rather than at run time.
Any language would be benefited from test-driven development, python
needs it because of its dynamic nature.

We can use "need" in the strict sense, as in "the language won't work
without it". I think we can reject that as too strong, because clearly
Python can work without unittests or any other sort of testing.

In the looser sense of "this will benefit you", I think it is fair to say
that *all* languages need test-driven development. If you want your code
to do some non-trivial task X, and you don't actually test to see if
it really does do X, then all the compiler tests in the world won't tell
you that your code is doing X.

Of course, the IT world is full of people writing code and not testing
it, or at least not testing it correctly. That's why there are frequent
updates or upgrades to software that break features that worked in the
older version. That would be impossible in a test-driven methodology, at
least impossible to do by accident.
And I don't think Haskell make the programmer do a lot of work(just
because of its static type checking at compile time).

I could be wrong, but I think Haskell is *strongly* typed (just like
Python), not *statically* typed. At least the "What Is Haskell?" page at
haskell.org describes the language as strongly typed, non-strict, and
allowing polymorphic typing.

--
Steven.

[bonono]

Steven D'Aprano wrote:

And I don't think Haskell make the programmer do a lot of work(just
because of its static type checking at compile time).

I could be wrong, but I think Haskell is *strongly* typed (just like
Python), not *statically* typed. At least the "What Is Haskell?" page at
haskell.org describes the language as strongly typed, non-strict, and
allowing polymorphic typing.

What is your definition of statically typed ? The non-strict as far as
I know is not referring to type checking. It does check type at compile
time though it is quite different from language like C, Java, the
polymorphic typing.

[D H]

Fredrik Lundh wrote:

Write code, not usenet posts.

QOTW!

[bonono]

Ernst Noch wrote:

Matthias Kaeppler wrote:

Brian Beck wrote:

def foo(self):
raise NotImplementedE rror("Subclasse s must implement foo")

That's actually a good idea, though not as nice as a check at
"compile-time" (jesus, I'm probably talking in C++ speech again, is
there such a thing as compile-time in Python at all?!)

Another thing which is really bugging me about this whole dynamically
typing thing is that it seems very error prone to me:

foo = "some string!"

# ...

if (something_fuba r):
fo = "another string"

Oops, the last 'o' slipped, now we have a different object and the
interpreter will happily continue executing the flawed program.

I really see issues with this, can anyone comment on this who has been
working with Python more than just a day (like me)?

Regards,
Matthias

Matthias,

maybe this article is of interest for you:
http://www.mindview.net/WebLog/log-0025

And two related ones.

http://www.algorithm.com.au/mt/progr...ic_typing.html

Just follow the links.

[Matthias Kaeppler]

gene tani wrote:

http://naeblis.cx/rtomayko/2004/12/1...c-method-thing
http://dirtsimple.org/2004/12/java-i...on-either.html
http://dirtsimple.org/2004/12/python-is-not-java.html

http://idevnews.com/PrintVersion_Cas...&Go2=Go&ID=118
http://www.idevnews.com/PrintVersion...cks.asp?ID=107
http://www.eros-os.org/pipermail/e-l...ne/005337.html

First of all, thanks everybody for posting all these answers and links,
much appreciated. What Bruce Eckel wrote about dynamic typing was quite
convincing and reasonable.

I stumbled over this paragraph in "Python is not Java", can anyone
elaborate on it:

"In Java, you have to use getters and setters because using public
fields gives you no opportunity to go back and change your mind later to
using getters and setters. So in Java, you might as well get the chore
out of the way up front. In Python, this is silly, because you can start
with a normal attribute and change your mind at any time, without
affecting any clients of the class. So, don't write getters and setters."

Why would I want to use an attribute in Python, where I would use
getters and setters in Java? I know that encapsulation is actually just
a hack in Python (common, "hiding" an implementation detail by prefixing
it with the classname so you can't access it by its name anymore? Gimme
a break...), but is that a reason to only write white box classes? ^^

- Matthias

[Matthias Kaeppler]

bo****@gmail.co m wrote:

Just follow the links.

I'll try ;-)

[Steven D'Aprano]

On Sun, 11 Dec 2005 07:10:27 -0800, bonono wrote:

Steven D'Aprano wrote:

> And I don't think Haskell make the programmer do a lot of work(just
> because of its static type checking at compile time).

I could be wrong, but I think Haskell is *strongly* typed (just like
Python), not *statically* typed. At least the "What Is Haskell?" page at
haskell.org describes the language as strongly typed, non-strict, and
allowing polymorphic typing.

What is your definition of statically typed ? The non-strict as far as
I know is not referring to type checking. It does check type at compile
time though it is quite different from language like C, Java, the
polymorphic typing.

Strongly typed means that objects have a type. All objects in Python have
a type.

Strongly typed languages like Python forbid you from performing operations
on mismatched types, e.g. 1 + "1" does not work. In order to perform
operations on mismatched types, you must explicitly perform a conversion,
e.g. 1 + int("1").

Weakly typed languages do not prevent you performing operations on
mismatched types, e.g. something like 1 + "1" is allowed in languages like
Basic and Perl.

Untyped languages do not have any type information at all -- everything
is just bytes. The most obvious example is assembly language.

It should be noted that strong and weak typing is a matter of degree:
despite being mostly strongly typed, Python does do automatic coercion of
ints and floats, and although it is (arguably) weakly typed, Perl won't
allow you to treat scalars as arrays or vice versa.

Dynamic typing means that variables can be dynamically set to objects of
wildly different types. For Python, we would say that any name can be
bound to any object of any type.

Static typing is the opposite of dynamic typing. Once a variable or
name is defined as a certain type (either by a declaration, or
implicitly the first time it is used), it can only be assigned to values
of that same type.

These two articles may be helpful:

http://www.voidspace.org.uk/python/a...k_typing.shtml
http://www.artima.com/forums/flat.js...06&thread=7590
A thoughtful defence of static typing is here:

http://www.xoltar.org/misc/static_typing_eckel.html

The fact that it is sub-titled "How Java/C++/C# Ruin Static Typing for the
Rest of Us" should give some idea what it is about.
--
Steven.

[Paul Boddie]

Heiko Wundram wrote:

Maybe I'm assuming things by thinking that others also follow my line of
thought, but I've actually had very positive responses so far when telling
people that a certain feature is a certain way and then pointing them to
the ZoP, they all pretty much told me after a certain time of thought that
"the decision made sense now."

Sorry to come across all harsh on the subject. Perhaps you know people
who are more meditative than I do, but I notice that you served up some
concrete advice elsewhere in the thread, so if the ZoP doesn't provide
any guidance to the questioner as it is, at least there's something
else to read through and grasp.

Paul