Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Dan Strohl <D.Strohl@F5.com>
Newsgroups: comp.lang.python
Subject: RE: Question on keyword arguments
Date: Thu, 18 Feb 2016 15:39:38 +0000
Lines: 116
Message-ID: <mailman.6.1455810052.2289.python-list@python.org>
References: <62136715E19142B6B318EA3A3DF04D40@OPTIPLEX990> <na4kut$ru8$1@ger.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Thread-Topic: Question on keyword arguments
Thread-Index: AQHRalZw8Vry/OGpuU6zQYVjWAdBQ58x33/kgAAJ84A=
In-Reply-To: <na4kut$ru8$1@ger.gmane.org>
Accept-Language: en-US
Content-Language: en-US
Precedence: list
Xref: csiph.com comp.lang.python:103123

I have approached this in a few different ways, depending on the use case.

I have done the "return_type=3Dlist" before, though I don't really like it.=
.. it's too easy to forget or mistype the exact name used for the switch.  =
If you do this, I also recommend setting some class or module variables to =
the text strings and pass those back and forth.

I have also returned a different type depending on what is being requested.=
.. so, if the function user requests data that has multiple objects, return=
 a list, if they request something that has just one object, return that ob=
ject.  This also has potential problems if the number of returned objects i=
s not consistently predictable, you would have to always test your returned=
 object to see how to handle it.

I like the other suggestions thrown out as well, (having multiple methods a=
nd having one method and a converting function).. They are good, easy to re=
ad and use methods as long as you know at design time what type of object y=
ou want (which is probably the norm).

Another approach that I like (where it makes sense) is to return another (c=
ustom) object that can act like either... that way, you have the content in=
 hand and can use it either way.  This approach works well when there is a =
high overhead in creating the data, that you don't want to have to do again=
, and you don't mind having a few more objects hanging around until cleaned=
 up.

So, define a return object like:

from collections import UserList
class TestResponse(UserList):
    def __str__(self):
        return '\0xfe%s' % '\0xfe'.join(self.data)

...and return that object.

that way, you can iterate over it, treat it as a list, or whatever, or if y=
ou do print(str(TestResponse)), you get your r'0xfeONE\0exfeTWO\0xfeTHREE'

In the end, your decision should be made based on:
1.  What would the developer using this EXPECT to get back? (if the user no=
rmally expects one or the other, do that, if this is for a "public module",=
 I would expect the list is more likely the common response.  This list is =
probably not the right place for that question though, unless this is a ver=
y general utility, you want to ask the people coding in the domain that wou=
ld mostly be using your function.)

2.  What is the most likely response type? (if it is common to get it back =
different ways, or use it multiple times, this is probably mostly the same =
as #1, but can be different)

3.  What will be the easiest to read and document?  Returning a list is eas=
y to read and expectable, but not if you have to then jump through some loo=
ps to convert it to something else immediately.

4.  Is there a large enough benefit in processing that you want to be able =
to use it multiple ways without having to regenerate the list.  (note that =
this is the last criteria, unless performance is really critical, readabili=
ty and predictability is normally much more important than what is probably=
 minor performance tuning.)

Dan Strohl


> -----Original Message-----
> From: Python-list [mailto:python-list-bounces+d.strohl=3Df5.com@python.or=
g] On
> Behalf Of Peter Otten
> Sent: Thursday, February 18, 2016 6:37 AM
> To: python-list@python.org
> Subject: Re: Question on keyword arguments
>=20
> grsmith@atlanticbb.net wrote:
>=20
> > Would this be the correct way to return a list as a default result.
>=20
> If it does what you want it to do it is "correct" as in "complies with
> specification".
>=20
> > Also, would the list be the preferable result (to a python programmer) =
?
>=20
> A list as a return value is OK as is any other object, however,
>=20
> > def test(command, return_type=3D'LIST'):
>=20
> passing the desired result type as an argument is usually not a good idea=
.
>=20
> >     """ Go to database and return data"""
> >     if return_type =3D=3D 'LIST':
> >         result =3D ['ONE', 'TWO', 'THREE']
> >     else:
> >         result =3D r'0xfeONE\0exfeTWO\0xfeTHREE'
> >     return result
> >
> > if __name__ =3D=3D '__main__':
> >     print(test('cmd'))
> >     print(test('cmd', 'LIST'))
> >     print(test('cmd', None))
> >     print(test('cmd', 'string'))
>=20
> Make it separate functions instead:
>=20
> def test(command):
>     return ["ONE", "TWO", "THREE"]
>=20
> def test_as_string(command, sep=3D","):
>     return sep.join(test(command))
>=20
> if __name__ =3D=3D '__main__':
>     print(test("cmd"))
>     print(test_as_string("cmd"))
>=20
>=20
> --
> https://mail.python.org/mailman/listinfo/python-list