[Python-ideas] kwargs for return

I know this is going to get rejected, but I want to speak out the idea nevertheless: I love kwargs and named arguments from the beginning (roughly 18 years now) I guess you came across this several times before: In the first version of the API one variable gets returned: Example:     status

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 02:04:12PM +0100, Thomas Güttler Lists wrote: > Example: > >     status = backend.transmit_data() > > But later you want to add something to the API. [...] > How could kwargs for return look like? return {'status': True, 'messages': []} Or perhaps better: return ResultO

Re: [Python-ideas] kwargs for return

> I don't see anything here that can't be done by returning a dict, a > namedtuple (possibly with optional fields), or some other object with > named fields. They can be optional, they can have defaults, and you can > extend the object by adding new fields without breaking backwards > compati

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019, 6:30 AM Anders Hovmöller > > I don't see anything here that can't be done by returning a dict, a > > namedtuple (possibly with optional fields), or some other object with > > named fields. They can be optional, they can have defaults, and you can > > extend the object by addi

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 03:29:59PM +0100, Anders Hovmöller wrote: > > > I don't see anything here that can't be done by returning a dict, a > > namedtuple (possibly with optional fields), or some other object with > > named fields. They can be optional, they can have defaults, and you can > > e

Re: [Python-ideas] kwargs for return

I was going to write exactly they're same idea Steven did. Right now you can simply design APIs to return dictionaries or, maybe better, namedtuples. Namedtuples are really nice since you can define new attributes when you upgrade an API without breaking any old coffee that used the prior attribut

Re: [Python-ideas] kwargs for return

On Saturday, January 26, 2019, Steven D'Aprano wrote: > > > Perhaps you should start by telling us *precisely* what the problem is > that your subclass will solve. Because I don't know what your idea of > dict unpacking is, and how it compares or differs from previous times it > has been proposed.

Re: [Python-ideas] kwargs for return

On Saturday, January 26, 2019, David Mertz wrote: > I was going to write exactly they're same idea Steven did. > > Right now you can simply design APIs to return dictionaries or, maybe > better, namedtuples. Namedtuples are really nice since you can define new > attributes when you upgrade an API

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 10:31 AM Steven D'Aprano 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. Se

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 12:01:55PM -0500, Wes Turner wrote: > Tuples are a dangerous (and classic, legacy) interface contract. What? -- Steve ___ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 11:59:36AM -0500, Wes Turner wrote: > This about object destructuring in JS is worth a read: > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Object_destructuring Thanks. -- Steve __

Re: [Python-ideas] kwargs for return

On 1/26/2019 12:30 PM, David Mertz wrote: On Sat, Jan 26, 2019 at 10:31 AM Steven D'Aprano > 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

Re: [Python-ideas] kwargs for return

Indeed! I promise to use dataclass next time I find myself about to use namedtuple. :-) I'm pretty sure that virtually all my uses will allow that. On Sat, Jan 26, 2019, 1:09 PM Eric V. Smith > > On 1/26/2019 12:30 PM, David Mertz wrote: > > On Sat, Jan 26, 2019 at 10:31 AM Steven D'Aprano >

Re: [Python-ideas] kwargs for return

I think I "get" what Thomas is talking about here: Starting with the simplest example, when defining a function, you can have one take a single positional parameter: def fun(x): ... and you can have code all over the place that calls it: fun(something) Later on, if you want to exapand the

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 10:13 AM David Mertz 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

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019, 1:21 PM Christopher Barker > As I understand it, functions return either a single value, or a tuple of > values -- there is nothing special about how assignment is happening when a > function is called. > No. It's simpler than that! Functions return a single value, period.

Re: [Python-ideas] kwargs for return

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 th

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 10:43 AM David Mertz wrote: > No. It's simpler than that! Functions return a single value, period. > > That single value might happen to be a tuple or something else unpackable. > d'uh -- I was thinking common use case. > This makes it feel like we have multiple return

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 10:20:11AM -0800, Christopher Barker wrote: > My first thought was that function return tuples, so you could document > that your function should be called as such: > > x = fun()[0] > > but, alas, tuple unpacking is apparently automatically disabled for single > value tup

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 4:01 PM Steven D'Aprano wrote: > On Sat, Jan 26, 2019 at 10:20:11AM -0800, Christopher Barker wrote: ... > but, alas, tuple unpacking is apparently automatically disabled for single > > value tuples (how do you distinguish a tuple with a single value and the > > value

Re: [Python-ideas] kwargs for return

On 27Jan2019 02:30, Steven D'Aprano wrote: On Sat, Jan 26, 2019 at 03:29:59PM +0100, Anders Hovmöller wrote: > I don't see anything here that can't be done by returning a dict, a > namedtuple (possibly with optional fields), or some other object with > named fields. They can be optional, they c

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 10:20:11AM -0800, Christopher Barker wrote: [...] > Starting with the simplest example, when defining a function, you > can have one take a single positional parameter: [...] > Later on, if you want to exapand the API, ytou can add a keyword parameter: > > def fun(x, y=No

Re: [Python-ideas] kwargs for return

On Sun, Jan 27, 2019 at 03:33:15PM +1100, Cameron Simpson wrote: > I don't think so. It looks to me like Thomas' idea is to offer a > facility a little like **kw in function, but for assignment. Why **keyword** arguments rather than **positional** arguments? Aside from the subject line, what pa