Newbie question: how to join a list of elements of user-defined types?

[Carl Banks]

Benjamin Han wrote:
> On Monday 29 April 2002 10:02 pm, Cliff Wells wrote:
>> On 29 Apr 2002 18:54:12 -0700
>>
>> Fortepianissimo wrote:
>> > This question is so fundamental that I strongly suspect it's already
>> > answered - ig that's the case, please forgive this poor newbie, for he
>> > has done some work searching over Python FAQ and Google.
>> >
>> > Basically I want to have a subclass of list, like
>> >
>> > class MyList (list):
>> >     ...
>> >
>> > then I want to
>> >
>> > l=MyList()
>> > ... do stuff to fill l
>> > s=" ".join(l)
>>
>> s = " ".join([str(i) for i in l])
> 

> This surely looks nicer. I'm just wondering how far Python has fared
> in terms of this concept of OO? This example seems to show a very
> different character of OO in Python, in that __str__ is not
> automatically called, which seems rather counter-intuitive.

It may seem counterintuitive for someone accustomed to a language
using typecast operators.  But, despite appearances, __str__ isn't
typecast operator.  In fact, Python doesn't have typecast operators.
If you want a type changed, you have to do it by hand.

But even if __str__ was a typecast, it still wouldn't be called, since
Python doesn't have overloaded functions.  The interpreter has no way
of knowing that " ".join is expecting a list of strings.  The join
method could have, as a convenience, converted non-string items to
strings itself, but there is never any implicit conversion.

(Some of the built-in numberic types might have implicit conversion;
not sure of the details.)


But I don't see what all that has to do with OO, though.


> Without private members, and with seemingly complex ways of dealing
> with class members and methods - so what's the state of OO in
> Python? 

There are certainly some oddities in the object/class scheme.  On the
whole, I don't see much practical difference between C++ and Python
classes.  I use them pretty much the same way.

Concerning private members, I would say they're not the hallmark of OO
you might think they are.  C++ was my first OO language, and, perhaps
like you, I about freaked out when I saw a language that claimed to be
"object oriented" but didn't have private data members.




> Is it still rapidly evolving?

Well, they recently added this new-style class thingie.  I imagine
it'll be tuned up along the way, but I think it's the end of the
revolutionary changes for awhile.  Someone else who knows better than
I can answer.


> How much is an effort in
> converting Python into C++? Anyone would like to comment on some of
> these questions, or point to some article, FAQ (esp. helpful from a
> C++ programmer's point of view)?

Well, let me give you a little heads up on the differences you might
see.  Many C++ programmers are brought up to believe that C++ is
synonymous with OOP.  You seem to tend that way, with your idea that
implicit typecasting is an OO feature.  (If not, I apologize I seem
facetious.)

There's a whole world of OO stuff out there that doesn't do it the way
C++ does.  And that's not necessarily (and not probably) a bad thing.

Personally, I find C++'s OO to be the most constraining of all
languages I've tried, excepting Ada 95 (no interfaces, no MI, ugh).
Why?  Because you are forced to construct elaborate class hierarchies
to get the desired polymorphic behavior.

Imagine implementing a hierarchy of file-like classes.  File-like
objects have similarities, but there are a lot of options: input,
output, or both?  seekable or nonseekable?  buffered or nonbuffered?
lockable or nonlockable?  text or binary?  is it a file, a string, a
pipe, a socket, or something else?  are there any other exotic
options?

How do you implement all this in a class hierarchy?  Well, for
example, you could define a class such as
BufferedSeekableLockableInputBinaryFileWithIOCTL, which inherits from
classes such as InputFile, BufferedSeekableObject, ObjectWithIOCTL,
LockableObject, etc., which in turn inherit from deeper classes.
Then, your classes will implement only the methodd it actually needs,
and the compiler will make sure nothing lacking the appropriate method
can be called.

No one's going to do that, though.  Instead, they'll pick one or two
option (usually input/output and file/string) and build a heirarchy on
that.  Then, they'll have a member function such as isseekable to
determine whether you can call the seek method.

But isn't the point of OOP so that you can avoid this kind of thing?
Don't you want the compiler to keep track of whether a file-like
object is seekable or not?  Yes, you do.  You might not think you
don't, but that's probably only because C++ makes it really difficult
to do it right.


Python makes it easy to do it right.  You don't need to define all
those elaborate classes in Python, because, in Python, you can get
polymorphic behavior without inheritance.

This is, IMHO, THE BEST THING about Python.  You want a file-like
object?  No problem: just write a class whose objects look like a
file, and act like a file, and you have a file-like object.  Because
your class it doesn't inherit from anything, it doesn't have to
implement methods it doesn't need.  If seek makes sense for a
particular type, add it; if not, don't.  And if someone tries to call
seek on an unseekable file-like object, you set an exception.

Python frees you from the contraints of the class hierarchies.  You
can reserve inheritance for when you actually need to share code
between several types, and otherwise leave the class interfaces up to
the individual class.


What I'm trying to say here is dynamic typing is so much better and
FUN than static typing it isn't even funny.


I defintely suggest you try Python out and keep and open mind, and try
not to use inheritance unless your classes really need to share code.


-- 
CARL BANKS                                http://www.aerojockey.com
"Nullum mihi placet tamquam provocatio magna.  Hoc ex eis non est."