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

[bonono]

Magnus Lycka wrote:

Assume that you didn't use Python, but rather something with
static typing. How could you make a module such as my_module.py,
which is capable of working with any type that supports some
standard copy functionality and the +-operator?

The following is a very short Haskell function I defined which I hope
can give you some idea.

What it does is just take a generic list of things(I want to use it on
string) and break it up into a tuple using any object in token as
seperator (sort of C's strtok).

breakKeyword token xs =
case break (flip elem token) xs of
(_,[]) -> (xs,[])
(ys,z:zs) -> (ys, zs)

This is the function declaration derived by Haskell(I haven't specify
anything above about types)

*MyList> :type breakKeyword
breakKeyword :: (Eq a) => [a] -> [a] -> ([a], [a])

What it means is that breakKeyword can take any list of object type "a"
so long it belongs to the class Eq. It can be char, number or whatever
so long it is an instance of Eq.

All that is needed for my custom data type(whatever it is) is that it
must implment the compare function that "elem" would use to compare if
a given object is in the list of token.

*MyList> :type elem
elem :: (Eq a) => a -> [a] -> Bool

[Antoon Pardon]

Op 2005-12-14, Magnus Lycka schreef <ly***@carmen.s e>:

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

Magnus Lycka wrote:

I don't really know Haskell, so I can't really compare it
to Python. A smarter compiler can certainly infer types from
the code and assemble several implementations of an
algorithm, but unless I'm confused, this makes it difficult
to do the kind of dynamic linking / late binding that we do in
Python. How do you compile a dynamic library without locking
library users to specific types?
I don't know. I am learning Haskell(and Python too), long way to go
before I would get into the the usage you mentioned, if ever, be it
Haskell or Python.

Huh? I must have expressed my thoughts badly. This is trivial to
use in Python. You could for instance write a module like this:

### my_module.py ###
import copy

def sum(*args):
result = copy.copy(args[0])
for arg in args[1:]:
result += arg
return result

### end my_module.py ###

Then you can do:

from my_module import sum
sum(1,2,3) 6 sum('a','b','c' ) 'abc' sum([1,2,3],[4,4,4]) [1, 2, 3, 4, 4, 4]

Assume that you didn't use Python, but rather something with
static typing.

That depends on what you would call static typing.

Suppose we would add type declarations in python.
So we could do things like

int: a
object: b

Some people seem to think that this would introduce static
typing, but the only effect those staments need to have
is that each time a variable is rebound an assert statement
would implicitly be executed, checking whether the variable is
still an instance of the declared type.

(Assuming for simplicity that all classes are subclasses
of object so that all objects are instances of object.)
How could you make a module such as my_module.py,

In the above scenario in just the same way as in python.

--
Antoon Pardon

[Christopher Subich]

Antoon Pardon wrote:

Suppose we would add type declarations in python.
So we could do things like

int: a
object: b

Some people seem to think that this would introduce static
typing, but the only effect those staments need to have
is that each time a variable is rebound an assert statement
would implicitly be executed, checking whether the variable is
still an instance of the declared type.

Doesn't work; duck typing is emphatically not subclass-typing. For this
system to still work and be as general as Python is now (without having
to make all variables 'object's), we'd need true interface checking.
That is, we'd have to be able to say:

implements + like int: a

or somesuch. This is a Hard problem, and not worth solving for the
simple benefit of checking type errors in code.

It might be worth solving for dynamic code optimization, but that's
still a ways off.

[Magnus Lycka]

Christopher Subich wrote:

Doesn't work; duck typing is emphatically not subclass-typing. For this
system to still work and be as general as Python is now (without having
to make all variables 'object's), we'd need true interface checking.
That is, we'd have to be able to say:

implements + like int: a

or somesuch. This is a Hard problem, and not worth solving for the
simple benefit of checking type errors in code.

It might be worth solving for dynamic code optimization, but that's
still a ways off.

Correct, but he's just trolling you know. What he suggests isn't
static typing, and he knows it. It gives all the rigidity of static
typing with only a tiny fraction of the claimed benefits, but it would
give a hefty performance penalty.

[Mike Meyer]

Magnus Lycka <ly***@carmen.s e> writes:

Huh? I must have expressed my thoughts badly. This is trivial to
use in Python. You could for instance write a module like this:

### my_module.py ###
import copy

def sum(*args):
result = copy.copy(args[0])
for arg in args[1:]:
result += arg
return result

### end my_module.py ###

Then you can do:

>>> from my_module import sum
>>> sum(1,2,3) 6 >>> sum('a','b','c' ) 'abc' >>> sum([1,2,3],[4,4,4]) [1, 2, 3, 4, 4, 4] >>>

Assume that you didn't use Python, but rather something with
static typing. How could you make a module such as my_module.py,
which is capable of working with any type that supports some
standard copy functionality and the +-operator?

CLU had this decades ago. You'd right something like:

def sum(*args) args has +=:
...

Basically, it did duck typing, checked at compile time instead of
dynamically.

<mike
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Donn Cave]

In article <11************ **********@g47g 2000cwa.googleg roups.com>,
bo****@gmail.co m wrote:

Magnus Lycka wrote:

Assume that you didn't use Python, but rather something with
static typing. How could you make a module such as my_module.py,
which is capable of working with any type that supports some
standard copy functionality and the +-operator?
The following is a very short Haskell function I defined which I hope
can give you some idea.

....
*MyList> :type breakKeyword
breakKeyword :: (Eq a) => [a] -> [a] -> ([a], [a])

What it means is that breakKeyword can take any list of object type "a"
so long it belongs to the class Eq. It can be char, number or whatever
so long it is an instance of Eq.

All that is needed for my custom data type(whatever it is) is that it
must implment the compare function that "elem" would use to compare if
a given object is in the list of token.

*MyList> :type elem
elem :: (Eq a) => a -> [a] -> Bool

Moreover, 1) this compare implementation is (as I understand it)
made available via runtime information, so a typeclass instance
may be implemented after the function that encounters it was compiled,
and 2) implementation often requires no more than "deriving Eq"
after the data type declaration -- assuming the data type is
composed of other types of data, you can infer the functional
composition of a typeclass instance.

The sum function in my_module.py was, in a very approximate sense,
like the standard "foldr" function. Of course foldr doesn't need to
copy, nor does it use any += operator. foldr is generic to any
function of type (a -> a -> b) (i.e., takes two parameters of one
type and returns a value of another type.) Lists don't support
a (+) operation (numeric only), but they support (++) concatenation
and (:) composition. foldr also takes an initial parameter of type b.

so,
foldr (:) "" ['a', 'b', 'c']
foldr (++) [] [[1, 2, 3], [4, 4, 4]]

Really, this kind of abstraction of data types is not only well
supported in Haskell, it can be almost a curse, at least for
someone like myself who has fairly superficial experience with
this kind of programming. After all the functions have been
zealously scrubbed clean of any trace of concrete data types and
rendered maximally abstract, they can be a little hard to understand.

Donn Cave, do**@u.washingt on.edu

[bonono]

Donn Cave wrote:

Really, this kind of abstraction of data types is not only well
supported in Haskell, it can be almost a curse, at least for
someone like myself who has fairly superficial experience with
this kind of programming. After all the functions have been
zealously scrubbed clean of any trace of concrete data types and
rendered maximally abstract, they can be a little hard to understand.

My experience too. An interesting thing I experienced with Haskell is
that even though it is strongly and statically typed, I seldom think
about data types when writing programs, kind of typeless to me.

[Alex Martelli]

<bo****@gmail.c om> wrote:

those convoluted templates that were added to the language as
an afterthought.

I don't see this in Haskell.

Well, historically templates HAVE been added to Haskell "as an
afterthought" (well after the rest of the language was done), and
judging mostly from
<http://research.microsoft.com/~simon...l/meta-haskell
..ps> it doesn't seem unfair to call them "convoluted "...
Alex

[bonono]

Alex Martelli wrote:

<bo****@gmail.c om> wrote:

those convoluted templates that were added to the language as
an afterthought.

I don't see this in Haskell.

Well, historically templates HAVE been added to Haskell "as an
afterthought" (well after the rest of the language was done), and
judging mostly from
<http://research.microsoft.com/~simon...l/meta-haskell
.ps> it doesn't seem unfair to call them "convoluted "...

I think I was talking about the need to add templates in order for
writing generic functions that was mentioned(see the example given
about sum), not in the context you are talking about. You seem to have
skipped the other half of the text I quoted.

[Alex Martelli]

<bo****@gmail.c om> wrote:

Alex Martelli wrote:

<bo****@gmail.c om> wrote:

> those convoluted templates that were added to the language as
> an afterthought.
I don't see this in Haskell.

Well, historically templates HAVE been added to Haskell "as an
afterthought" (well after the rest of the language was done), and
judging mostly from
<http://research.microsoft.com/~simon...l/meta-haskell
.ps> it doesn't seem unfair to call them "convoluted "...

I think I was talking about the need to add templates in order for
writing generic functions that was mentioned(see the example given
about sum), not in the context you are talking about. You seem to have
skipped the other half of the text I quoted.

Right, you can get good genericity with Haskell's typeclasses (I've
posted about that often in the past, and desperately and so far
unsuccessfully tried to convince Guido to use something close to
typeclasses rather than "interfaces " for such purposes as PEP 246
[protocol adaptation]); it's the state of _templates_ in Haskell,
specifically, which I was rather dubious about (it may be that I just
haven't dug into them deep enough yet, but they do seem not a little
"convoluted " to me, so far).
Alex