[Python-ideas] kwargs for return

[David Mertz]

I'm not certain of memory usage. But using 'make_dataclass' makes the
"noise" pretty much no worse than namedtuple.

Person = namedtuple("Person", "name age address")
Person = make_dataclass("Person", "name age address".split())

Unless you have millions of there's objects, memory probably isn't that
important. But I guess you might... and namedtuple did sell itself as "less
memory than small dictionaries"

On Sat, Jan 26, 2019, 1:26 PM Christopher Barker <pythonchb at gmail.com wrote:

> On Sat, Jan 26, 2019 at 10:13 AM David Mertz <mertz at gnosis.cx> wrote:
>
>> Indeed! I promise to use dataclass next time I find myself about to use
>> namedtuple. :-)
>>
>
> Indeed IIUC, namedtuple was purposely designed to be able to replace
> tuples as well as adding the named access.
>
> But that does indeed cause potential issues. However, dataclasses see kind
> of heavyweight to me -- am I imagining that, or could one make a
> named_not_tuple that was appreciably lighter weight? (in creation time,
> memory use, that sort of thing)
>
> -CHB
>
>
>
>
>
>
>
>>
>> I'm pretty sure that virtually all my uses will allow that.
>>
>> On Sat, Jan 26, 2019, 1:09 PM Eric V. Smith <eric at trueblade.com wrote:
>>
>>>
>>>
>>> On 1/26/2019 12:30 PM, David Mertz wrote:
>>> > On Sat, Jan 26, 2019 at 10:31 AM Steven D'Aprano <steve at pearwood.info
>>> > <mailto:steve at pearwood.info>> wrote:
>>> >
>>> >     In what way is it worse, given that returning a namedtuple with
>>> named
>>> >
>>> >     fields is backwards compatible with returning a regular tuple? We
>>> can
>>> >     have our cake and eat it too.
>>> >     Unless the caller does a type-check, there is no difference.
>>> Sequence
>>> >     unpacking will still work, and namedtuples unlike regular tuples
>>> can
>>> >     support optional attributes.
>>> >
>>> >
>>> > I suppose the one difference is where someone improperly relies on
>>> tuple
>>> > unpacking.
>>> >
>>> > Old version:
>>> >
>>> >     def myfun():
>>> >          # ...
>>> >          return a, b, c
>>> >
>>> >     # Call site
>>> >     val1, val2, val3 = myfun()
>>> >
>>> >
>>> > New version:
>>> >
>>> >     def myfun():
>>> >          # ...
>>> >          return a, b, c, d
>>> >
>>> >
>>> > Now the call site will get "ValueError: too many values to unpack".
>>> > Namedtuples don't solve this problem, of course.  But they don't make
>>> > anything worse either.
>>> >
>>> > The better approach, of course, is to document the API as only using
>>> > attribute access, not positional.  I reckon dataclasses from the start
>>> > could address that concern... but so can documentation alone.  E.g.:
>>> >
>>> > Old version (improved):
>>> >
>>> >     def myfun():
>>> >
>>> >          mydata = namedtuple("mydata", "a b c")
>>> >
>>> >          # ...
>>> >          return mydata(a, b, c)
>>> >
>>> >     # Call site
>>> >     ret = myfun()
>>> >
>>> >     val1, val2, val3 = ret.a, ret.b, ret.c
>>> >
>>> >
>>> > New version (improved)
>>> >
>>> >     def myfun():
>>> >
>>> >          mydata = namedtuple("mydata", "a b c d e")
>>> >
>>> >          # ...
>>> >          return mydata(a, b, c, d, e)
>>> >
>>> > Now the call site is completely happy with no changes (assuming it
>>> > doesn't need to care about what values 'ret.d' or 'ret.e' contain...
>>> but
>>> > presumably those extra values are optional in some way.
>>> >
>>> > Moreover, we are even perfectly fine if we had created
>>> > namedtuple("mydata", "e d c b a") for some reason, completely changing
>>> > the positions of all the named attributes in the improved namedtuple.
>>>
>>> Preventing this automatic unpacking (and preventing iteration in
>>> general) was one of the motivating factors for dataclasses:
>>> https://www.python.org/dev/peps/pep-0557/#id47
>>>
>>> Eric
>>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190126/63b52efe/attachment-0001.html>