A tuple in order to pass returned values ?

Discussion in 'Python' started by faucheuse, Oct 5, 2011.

  1. faucheuse

    faucheuse Guest

    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, Oct 5, 2011
    #1
    1. Advertising

  2. 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, Oct 6, 2011
    #2
    1. Advertising

  3. 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, Oct 7, 2011
    #3
  4. 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 :eek:) ), too bad it is
    available only from python 2.6.

    JM
    Jean-Michel Pichavant, Oct 7, 2011
    #4
  5. faucheuse

    alex23 Guest

    Jean-Michel Pichavant <> 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
    alex23, Oct 10, 2011
    #5
  6. faucheuse

    Roy Smith Guest

    In article
    <>,
    alex23 <> wrote:

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


    Particularly useful for handing over lupins.
    Roy Smith, Oct 10, 2011
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michal Mikolajczyk
    Replies:
    1
    Views:
    792
    Larry Bates
    Apr 20, 2004
  2. Jeff Epler
    Replies:
    0
    Views:
    923
    Jeff Epler
    Apr 20, 2004
  3. Bill Scherer
    Replies:
    0
    Views:
    602
    Bill Scherer
    Apr 20, 2004
  4. Gregor Horvath

    Why tuple with one item is no tuple

    Gregor Horvath, Mar 15, 2005, in forum: Python
    Replies:
    37
    Views:
    793
    Antoon Pardon
    Mar 30, 2005
  5. faucheuse
    Replies:
    4
    Views:
    132
    Dave Angel
    Oct 5, 2011
Loading...

Share This Page