how to mutate a tuple?

[John Roth]

"Carlo v. Dango" <oest at soetu.eu> wrote in message
news:oprw1es0z9myya52 at news.kadnet.dom...
> On Tue, 14 Oct 2003 10:14:25 -0400, John Roth <newsgroups at jhrothjr.com>
> wrote:
>
> >
> > "Carlo v. Dango" <oest at soetu.eu> wrote in message
> > news:oprw1cm4ytmyya52 at news.kadnet.dom...
> >> On Tue, 14 Oct 2003 09:33:46 -0400, Roy Smith <roy at panix.com> wrote:
> >>
> >> Many thanks for your quick reply!
> >>
> >> aaaahh so there is a tuper() construct! :) that helps a lot.. still
this
> >> seems rather inefficient to create a list and then a new tuple.. but I
> >> guess there really is no easier way.
> >>
> >> but is there a tuple=>list function ? so that instead of creating the
> >> list
> >> by a for-construct I could just say
> >>
> >> list = tuple.tolist()
> >> list[0] = newval
> >> return turple(list)
> >
> > No. If you think about it, for such a method to work, it would have
> > to change the object in place from a tuple to a list,
>
>
> sorry, the code should have been:  mylist = mytuple.tolist()

Ah. That's not a bad idea. Mostly it's a language
design decision. object.toSomeOtherType() designs put the
responsibility for converting on the 'from' object, languages
that overload their constructors (like Python) put the responsibility
on the 'to' object. Neither one is clearly better since neither one
gracefully handles the question of what to do when you add a new
type: there are always places where you can't easily add the
needed glue.

Python has chosen to go down the path of haveing one obviously
'right' way to do most tasks (as distinct from Perl, whose motto is
"there's more than one way to do it",) and it's chosen to put the
responsibility for type conversion on the constructor of the new type.

John Roth


>
>
> > If you need to mutate a tuple, then I'd begin to question
> > whether there isn't something else wrong with the design.
>
> I do.. I'd rather pass around a list.. but as I said I'm using the *args
> mechanism in python which is a tuple and not a list.
>
>
> -Carlo van Dango
>