«

Hi, (new to python and first message here \o/)

I was wondering something :
when you do : return value1, value2, value3
It returns a tuple.

So if I want to pass these value to a function, the function have to
look like :
def function(self,(value1, value2, value3)) #self because i'm working
with classes

I tried it, and it works perfectly, but I was wondering if it's a good
choice to do so, if there is a problem by coding like that.

So my question is : Is there a problem doig so ?

faucheuse wrote:
> Hi, (new to python and first message here \o/)
>
> I was wondering something :
> when you do : return value1, value2, value3
> It returns a tuple.
>
> So if I want to pass these value to a function, the function have to
> look like :
> def function(self,(value1, value2, value3)) #self because i'm working
> with classes
>
> I tried it, and it works perfectly, but I was wondering if it's a good
> choice to do so, if there is a problem by coding like that.
>
> So my question is : Is there a problem doig so ?
>
There is no problem with that but ppl will usually write something like:

def function(self, a3Tuple):
v1, v2 ,v3 = a3Tuple

In a general manner, ppl will tend to use the minimum arguments
required. However, do not pack values into tuple if they are not related.
A better thing to do would be to use objects instead of tuples, tuples
can serve as lazy structures for small application/script, they can
become harmful in more complexe applications, especialy when used in
public interfaces.

JM

Jean-Michel Pichavant wrote:

> In a general manner, ppl will tend to use the minimum arguments
> required. However, do not pack values into tuple if they are not related.

How would you return multiple values if not in a tuple?

Tuples are *the* mechanism for returning multiple values in Python. If
you're doing something else, you're wasting your time.


> A better thing to do would be to use objects instead of tuples, tuples
> can serve as lazy structures for small application/script, they can
> become harmful in more complexe applications, especialy when used in
> public interfaces.

First off, tuples *are* objects, like everything else in Python.

If you are creating custom classes *just* to hold state, instead of using a
tuple, you are wasting time. Instead of this:

class Record:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z

result = Record(1, 2, 3)

Just use a tuple or a namedtuple: the work is already done for you, you have
a well-written, fast, rich data structure ready to use. For two or three
items, or for short-lived results that only get used once, an ordinary
tuple is fine, but otherwise a namedtuple is much better:

from collections import namedtuple
result = namedtuple('Record', 'x y z')(1, 2, 3)



--
Steven

Steven D'Aprano wrote:
> Jean-Michel Pichavant wrote:
>
>
>> In a general manner, ppl will tend to use the minimum arguments
>> required. However, do not pack values into tuple if they are not related.
>>
>
> How would you return multiple values if not in a tuple?
>
> Tuples are *the* mechanism for returning multiple values in Python. If
> you're doing something else, you're wasting your time.
>
>
>
>> A better thing to do would be to use objects instead of tuples, tuples
>> can serve as lazy structures for small application/script, they can
>> become harmful in more complexe applications, especialy when used in
>> public interfaces.
>>
>
> First off, tuples *are* objects, like everything else in Python.
>
> If you are creating custom classes *just* to hold state, instead of using a
> tuple, you are wasting time. Instead of this:
>
> class Record:
> def __init__(self, x, y, z):
> self.x = x
> self.y = y
> self.z = z
>
> result = Record(1, 2, 3)
>
> Just use a tuple or a namedtuple: the work is already done for you, you have
> a well-written, fast, rich data structure ready to use. For two or three
> items, or for short-lived results that only get used once, an ordinary
> tuple is fine, but otherwise a namedtuple is much better:
>
> from collections import namedtuple
> result = namedtuple('Record', 'x y z')(1, 2, 3)
>
>
I don't have access to namedtuple, working with python 2.5
It sounds to me that namedtuple exactly tries to fix what I dislike in
tuples : undocumented packing of unrelated data.

However, I'm not sure it fixes the main issue: unpacking. Unpacking
prevents you from adding any additional fields to your 'tuple' without
breaking any line of code that was unpacking the tuple (to oppose to
accessing an object attribute). And it did annoy me a lot when improving
applications. Now I'm using tuples only in small applications, and try
to avoid unpacking as much as possible.

namedtuple sounds great (if you don't use unpacking ) ), too bad it is
available only from python 2.6.

JM

Jean-Michel Pichavant <jeanmic...@sequans.com> wrote:
> However, I'm not sure it fixes the main issue: unpacking. Unpacking
> prevents you from adding any additional fields to your 'tuple' without
> breaking any line of code that was unpacking the tuple (to oppose to
> accessing an object attribute).

Generally, if it's a small, known, unlikely-to-change structure, I'd
use a tuple. For anything else I'd use a class, namedtuple or bunch.

However, pre-namedtuples I'd usually abstract away the field
referencing with indices and lambdas:

name = 0
role = 1
name_role = lambda t: (t[name], t[role])

name, role = name_role(record)

etc

In article
<e8a3d9d1-7eb8-43c5-9ee1->,
alex23 <> wrote:

> For anything else I'd use [...] bunch.

Particularly useful for handing over lupins.