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

[Steve Holden]

"Benjamin Han" <bhan at andrew.cmu.edu> 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.
>
I'm not sure I'd agree - polymorphism doesn't necessarily imply type
conversion, which is what's required here. I agree it *is* annoying that the
.join() method will only join sequences of strings, and perhaps there is a
case for having it call the __str__() or __repr__() methods of the objects
it is dealing with (since the result is always going to be a string).

> Without private members, and with seemingly complex ways of dealing with
class
> members and methods - so what's the state of OO in Python? Is it still
> rapidly evolving? 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)?
>
The implementation of OO is currently in a state of rapid development. Until
2.2 the user-defined classes were entirely separate from the built-in types,
but they have moved much closer together, with a view to eventually making
everything a first-class object and allowing sensible subclassing of int,
dict and the other built-ins.

These changes have been made without introducing any significant backward
incompatibilities (for some value of significant). This has not stopped the
user community expressing collective nervousness, despite the remarkably
short list of actual code breakages triggered by relatively recent change.

Python is pretty much WYSIWYG in object terms. It has enough introspection
to make fully dynamic programming and the creation of IDEs possible and
natural. Of course, this makes it easier for the adventurous programmer to
shoot zieself (zerself? Aahz?) in the foot. By and large Pythonistas are
prepared to forego the protection of privacy as implemented in (say) Java or
C++ for the flexibility of being able to do more interesting stuff.

As far as I am aware there is no existing effort to translate Python into
C++. A Python to C translator was, I believe, abandoned and languishes. Some
interesting work has been done into using compiling techniques on Python
functions (Google for Psyco, I think), and gainsays some of the conventional
wisdom about Python's dynamic typing not being well-suited to compilation.

A C++ translator that worked and produced measurable speedups over existing
interpreters would win its implementor the undying affection of many Python
programmers. The remaining 115% would spend their time complaining that the
language still didn't implement the ternary choice operator :0)

regards
 Steve
--

Steve Holden: http://www.holdenweb.com/ ; Python Web Programming:
http://pydish.holdenweb.com/pwp/