A tuple in order to pass returned values ?

[faucheuse]

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 ?

[Daniel Dorani]

this feature has been removed in python3 in accordance to the PEP 3113 (http://www.python.org/dev/peps/pep-3113/), you should consider using the * operator http://docs.python.org/tutorial/controlflow.html#unpacking-argument-lists .

[Ulrich Eckhardt]

Am 05.10.2011 15:33, schrieb faucheuse:
> I was wondering something :
> when you do : return value1, value2, value3
> It returns a tuple.

Right.

> So if I want to pass these value to a function, the function have to
> look like :
> def function(self,(value1, value2, value3))

[...]

No, you don't have to, but you can:

# example functions
def fni():
return 1, 2
def fno(v1, v2):
pass

# store result in a tuple and unpack tuple for function call
t = fni()
fno(*fni)

# store results in individual values
v1, v2 = fni()
fno(v1, v2)


Note that the first variant can be written in a single line, too. A
completely different alternative is passing a tuple to the function as a
single parameter. You can then access the elements using normal tuple
indexing. That said, I don't see a problem with your syntax, except that
it's a bit unusual.


Welcome to Python!

Uli

[faucheuse]

Thanks for the answer.

[Dave Angel]

In the abstract, no. There's no relationship between the two, except
they happen to use the same name in their respective local namespaces.

In practice, I wouldn't do it. If the three values really comprise one
"thing" then it makes sense for a function to expect a single thing, and
that thing needs a name. So I'd define the function as

def function(self, mything):
interesting, useful, related = mything
... work on them

But it's certainly possible that the writer of the first function really
had three independent things to return, and if the second method is
expecting those same three independent things, he should define the
method as:

def function(self, this, that, theother):

Python does have magic syntax to make this sort of thing easier to work
with, using * and **. But I seldom use them unless forced to by
meta-concerns, such as passing unknown arguments through one method to a
method of a superclass.

DaveA

[Jean-Michel Pichavant]

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

[Steven D'Aprano]

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

[Jean-Michel Pichavant]

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 :o) ), too bad it is
available only from python 2.6.

JM

[Cameron Simpson]

On 07Oct2011 11:43, Jean-Michel Pichavant <jeanm...@sequans.com> wrote:
| namedtuple sounds great (if you don't use unpacking :o) ), too bad
| it is available only from python 2.6.

It is easy enough to roll your own.

Here's some example code with several flaws (it claims tuplehood,
but is actually a list; it is not immutable; it takes a list of field
names instead of a space separated string as namedtuple does) and isn't
very tested.

But feel free to take it and adapt it:

def NamedTupleClassFactory(*fields):
''' Construct classes for named tuples a bit like the named tuples
coming in Python 2.6/3.0.
NamedTupleClassFactory('a','b','c') returns a subclass of "list"
whose instances have properties .a, .b and .c as references to
elements 0, 1 and 2 respectively.
'''
class NamedTuple(list):
for i in range(len(fields)):
f=fields[i]
exec('def getx(self): return self[%d]' % i)
exec('def setx(self,value): self[%d]=value' % i)
exec('%s=property(getx,setx)' % f)
return NamedTuple

def NamedTuple(fields,iter=()):
''' Return a named tuple with the specified fields.
Useful for one-off tuples/lists.
'''
return NamedTupleClassFactory(*fields)(iter)

More old code:-( I can see I need to go back to that and make it
cleaner. Surely I can get rid of the exec(0s at least:-)

Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Hacker: One who accidentally destroys.
Wizard: One who recovers afterwards.

[Peter Otten]

Cameron Simpson wrote:

> On 07Oct2011 11:43, Jean-Michel Pichavant <jeanm...@sequans.com> wrote:
> | namedtuple sounds great (if you don't use unpacking :o) ), too bad
> | it is available only from python 2.6.
>
> It is easy enough to roll your own.

Or use Raymond Hettinger's implementation:

http://code.activestate.com/recipes/500261-named-tuples/

[alex23]

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

[Roy Smith]

In article
<e8a3d9d1-7eb8-43c5...@v29g2000prd.googlegroups.com>,
alex23 <wuw...@gmail.com> wrote:

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

Particularly useful for handing over lupins.