[SciPy-Dev] return named tuples

[Daniel da Silva]

Are the namedtuple subclasses used to create return values going to be made
available? If so, what's the convention on where they will be placed?

On Sun, Sep 7, 2014 at 1:04 AM, Clark Fitzgerald <clarkfitzg at gmail.com>
wrote:

> Agreed, consistent names are important. My general strategy is to use the
> function name as the `typename` parameter for namedtuple, and the
> equivalent Numpy function names for `field_names`.
>
> There's room for discussion here- if the function is `describe`, then the
> `typename` could be:
>
> 1) `describe`
> 3) `stats_describe`
> 2) `describe_out`
> 4) or something else
>
> It would be nice to have a standard for this naming convention as well.
>
> Regarding Josef's point about 'future proofing', it seems to me that it
> would be cleaner for the function to return a dict when this is
> anticipated. But this would only work for new code.
>
> Clark
>
>
> On Sat, Sep 6, 2014 at 12:59 PM, <josef.pktd at gmail.com> wrote:
>
>>
>>
>>
>> On Sat, Sep 6, 2014 at 3:10 PM, Warren Weckesser <
>> warren.weckesser at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Sat, Sep 6, 2014 at 12:54 PM, Clark Fitzgerald <clarkfitzg at gmail.com>
>>> wrote:
>>>
>>>> As a user, it would be convenient to access results by name. The
>>>> relevant issue on Github is #3665
>>>> <https://github.com/scipy/scipy/issues/3665>. For example:
>>>>
>>>> summary = scipy.stats.describe(data)
>>>>
>>>> The current way to access the mean is to write `summary[2]`. It would
>>>> be more clear to write `summary.mean`. I'd like to create a PR to implement
>>>> this using namedtuples. Here is the idea:
>>>>
>>>> from collections import namedtuple
>>>> from scipy.stats import describe, norm
>>>>
>>>>
>>>> data = norm().rvs(100)
>>>> unnamed = describe(data)
>>>>
>>>> output = namedtuple('describe', ('size', 'range', 'mean', 'variance',
>>>>                                  'skewness', 'kurtosis'))
>>>>
>>>> named = output(*unnamed)
>>>>
>>>> This doesn't break backwards compatibility since:
>>>>
>>>> In [8]: unnamed[2] == named[2] == named.mean
>>>> Out[8]: True
>>>>
>>>> This isn't limited to stats.describe; it would be beneficial anywhere
>>>> that the return object is a tuple that's possibly unclear.
>>>>
>>>> The feedback on the Git issue has been positive. More feedback welcome.
>>>>
>>>>
>>>
>>> Sounds good to me.  This could eventually be applied to many
>>> functions in scipy.
>>>
>>> Before adding this feature to a function, look for any related
>>> functions that might return similar values.   We should try to
>>> ensure that return values with the same meaning are consistently
>>> given the same name.  We should avoid, for example, one statistical
>>> test using "p", another using "pvalue" and third using "p_value".
>>>
>>> We'll also need to update our docstring standard to include guidelines
>>> for documenting such return values.
>>>
>>
>> It's nice for users, but doesn't help for developing the code.
>>
>> It's backwards compatible but not "future proof".
>> For example it's a pain that we cannot change the returns of linregress
>> to add some additional things because it would break the behavior as a
>> tuple.
>>
>> Josef
>>
>>
>>>
>>> Warren
>>>
>>>
>>>
>>>>
>>>> Best,
>>>> Clark Fitzgerald
>>>> Statistics phd student, UC Davis
>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20140909/c9544fc1/attachment.html>