[Python-ideas] Re: Keyword arguments self-assignment

I believe this is a different feature, non-exclusive to the one proposed here, that would also make it possible not to re-declare keywords. But implementing this change with the argument of making function calls less repetitive or verbose when having redundant named keywords and variables

[Python-ideas] Re: Keyword arguments self-assignment

On Apr 16, 2020, at 20:48, oliveira.rodrig...@gmail.com wrote: > > In Javascript ES6 they don't have sets built like python so `{}` always > refers to objects being constructed. It does indeed support implicit key: > value pairs, so in ES6 `{ a: a, b: x, c: c }` is equivalent to `{ a, b: x, c

[Python-ideas] Re: Keyword arguments self-assignment

@StevenDAprano we are discussing alternative syntaxes to enhance readability and in place of blank assignments `k=` we could possibly use a sole `*` character as indicative that the following parameters are all to be passed as keywords. In this syntax, the keyword to which the parameter will

[Python-ideas] Re: Keyword arguments self-assignment

@Steven D'Aprano see that it doesn't actually have to look like a pair, it doesn't need to be one at all. Just like in: ```python def f(a): ... f(x) ``` `x` is implicitly assigned with `a`, i.e. this is `x = a` under the hood and there is no need to think of a key-value pair `x: a`. The

[Python-ideas] Re: Keyword arguments self-assignment

On Thu, Apr 16, 2020 at 07:50:30PM +0200, Alex Hall wrote: > > > > And what would you do if you wanted to call: > > > > self.do_something(positional, keyword=keyword, keyword1=somethingelse, > > keyword2=keyword2) > > > > ? > > > > Eric > > > > I think this is still pretty clear: > >

[Python-ideas] Re: Keyword arguments self-assignment

On Thu, Apr 16, 2020 at 01:41:42PM -0400, Eric V. Smith wrote: > On 4/16/2020 1:30 PM, Rhodri James wrote: > >I beg to differ.  I do find "def foo(a, *, b)" gets in the way of > >readability. > > And what would you do if you wanted to call: > > self.do_something(positional, keyword=keyword,

[Python-ideas] Re: Keyword arguments self-assignment

On Thu, Apr 16, 2020 at 05:02:03PM -, oliveira.rodrig...@gmail.com wrote: > @ > > > Do any other languages already have this feature? > > JavaScript ES6 has similar feature: > > ```javascript > x = 1 > y = 2 > do_something({ x, y }) > ``` That certainly makes your suggested syntax look

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

On Thu, Apr 16, 2020 at 01:11:46PM -0300, Soni L. wrote: > we can't break setdefault (particularly for tuple keys), do you have a > better idea? Do nothing? I don't have to suggest a better idea, since its not me proposing a change. I don't think any change is needed. It is up to you to

[Python-ideas] Re: Proposed class for collections: dynamicdict

On Apr 16, 2020, at 12:26, Andrew Barnert wrote: > > Somewhere I have some code for a set of class decorators that help > implementing mappings and sequences: you provide basic __fooitem__ methods, > and it wraps them with methods that do all the extra stuff dict, tuple, and > list do. IIRC,

[Python-ideas] Re: Keyword arguments self-assignment

> On Apr 16, 2020, at 12:05, Dominik Vilsmeier wrote: > > I'm not sure if this is doable from the compiler perspective, but what > about allowing tuples after `**` unpacking: > >requests.post(url, **(data, params)) > ># similar to >requests.post(url, data=data, params=params) Is

[Python-ideas] Re: Keyword arguments self-assignment

On Thu, Apr 16, 2020 at 10:47 PM Dominik Vilsmeier wrote: > > On 16.04.20 22:28, Alex Hall wrote: > > On Thu, Apr 16, 2020 at 10:13 PM Kyle Stanley wrote: > >> Dominik Vilsmeier wrote: >> > I'm not sure if this is doable from the compiler perspective, but what >> > about allowing tuples after

[Python-ideas] Re: Keyword arguments self-assignment

On 16.04.20 22:28, Alex Hall wrote: On Thu, Apr 16, 2020 at 10:13 PM Kyle Stanley mailto:aeros...@gmail.com>> wrote: Dominik Vilsmeier wrote: > I'm not sure if this is doable from the compiler perspective, but what > about allowing tuples after `**` unpacking: > >     

[Python-ideas] Re: Keyword arguments self-assignment

On Thu, Apr 16, 2020 at 10:13 PM Kyle Stanley wrote: > Dominik Vilsmeier wrote: > > I'm not sure if this is doable from the compiler perspective, but what > > about allowing tuples after `**` unpacking: > > > > requests.post(url, **(data, params)) > > > > # similar to > >

[Python-ideas] Re: Keyword arguments self-assignment

You have a fair point @DominikVilsmeier though I still believe this can workout there are other alternatives up for discussion such as using the `=` character. You see: after a keyword parameter you cannot define other positional ones, so the new syntax can assume all parameters following a

[Python-ideas] Re: Keyword arguments self-assignment

Dominik Vilsmeier wrote: > I'm not sure if this is doable from the compiler perspective, but what > about allowing tuples after `**` unpacking: > > requests.post(url, **(data, params)) > > # similar to > requests.post(url, data=data, params=params) +1. I can see the practical

[Python-ideas] Re: Keyword arguments self-assignment

+1 on the idea, -1 on the syntax. i'm probably not a very skilled developer but i have found myself repeating variable names often enough that i've felt annoyed by it. alex hall's syntax suggested syntax seems nice. would be fun to be able to write: >>> a=1 >>> b=2 >>> dict(*, a, b) {'a': 1,

[Python-ideas] Re: Keyword arguments self-assignment

On Thu, Apr 16, 2020 at 10:02 AM wrote: > @ > > > Do any other languages already have this feature? > > JavaScript ES6 has similar feature: > > ```javascript > x = 1 > y = 2 > do_something({ x, y }) > ``` > Rust also has a similar feature when instantiating structs which are always

[Python-ideas] Re: Proposed class for collections: dynamicdict

On Apr 16, 2020, at 11:03, Caleb Donovick wrote: > > Or alternatively MissingMapping (or some other mixin) could define > __getitem__ and require __getitem_impl__ and __missing__. As this wouldn't > require any changes to anything I think it might be the best solution I have > proposed. I

[Python-ideas] Re: Keyword arguments self-assignment

I'm not sure if this is doable from the compiler perspective, but what about allowing tuples after `**` unpacking:     requests.post(url, **(data, params))     # similar to     requests.post(url, data=data, params=params) Probably some magic would need to happen in order to merge the names

[Python-ideas] Re: Keyword arguments self-assignment

For function definitions, the introduction of `*` to mark keyword-only parameters was consistent with existing syntax in a sense that `def foo(*args, bar)` had `args` consume all positional arguments, so `bar` can only be passed via keyword. Now using `def foo(*, bar)` just omits the positional

[Python-ideas] Re: Keyword arguments self-assignment

> > I’m not sure if this would work out the same way or not. And even if it > does, that hurdle of describing the syntax in a way that people won’t get > confused the way they do when they first learn the feature in C++ might be > hard to overcome. But it’s at least plausible that it could be

[Python-ideas] Re: Keyword arguments self-assignment

On Fri, Apr 17, 2020 at 3:03 AM wrote: > > (Steven D'Aprano) > > Do any other languages already have this feature? > > JavaScript ES6 has similar feature: > > ```javascript > x = 1 > y = 2 > do_something({ x, y }) > ``` Very few other languages even *have* keyword arguments, so the nearest

[Python-ideas] Re: Proposed class for collections: dynamicdict

> construction calls __init__ if __new__ returns an instance Actually type's __call__ method does that, although that doesn't help my point at all... Your point about there being no method to perform the dispatch is good. To get what I want without interpreter changes there would need to be

[Python-ideas] Re: Keyword arguments self-assignment

On Apr 16, 2020, at 11:04, Alex Hall wrote: > >> And what would you do if you wanted to call: >> >> self.do_something(positional, keyword=keyword, keyword1=somethingelse, >> keyword2=keyword2) >> >> ? >> >> Eric > > I think this is still pretty clear: > > self.do_something(positional, *,

[Python-ideas] Re: Keyword arguments self-assignment

On Apr 16, 2020, at 10:20, Calvin Spealman wrote: > > I could absolutely see a lot of use for this when it comes to rebinding names > in callbacks and the like. > > for i in range(10): > callLater(delay, lambda i=: print(i)) But that one wouldn’t be handled by the proposal. It’s explicitly

[Python-ideas] Re: Keyword arguments self-assignment

Thanks @AlexHall I believe your version is even better in readability. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/

[Python-ideas] Re: Keyword arguments self-assignment

> > And what would you do if you wanted to call: > > self.do_something(positional, keyword=keyword, keyword1=somethingelse, > keyword2=keyword2) > > ? > > Eric > I think this is still pretty clear: self.do_something(positional, *, keyword, keyword1=somethingelse, keyword2) but if you don't like

[Python-ideas] Re: Keyword arguments self-assignment

I'm really open to discuss how we can achieve this feature with clearer syntax than the first proposed version. If any of you have more ideas please share :) @EricVSmith I didn't thought it through about the syntax with the `*` character but your case is well covered: ``` self.do_something(

[Python-ideas] Re: Keyword arguments self-assignment

> > I beg to differ. I do find "def foo(a, *, b)" gets in the way of > readability. > > -- > Rhodri James *-* Kynesim Ltd > In what way? In any case, focusing on the calling syntax being proposed, is there anything unreadable about: foo(a, *, b) compared to foo(a, b=b) ? I think in the

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

On 2020-04-16 2:42 p.m., Andrew Barnert wrote: On Apr 16, 2020, at 07:19, Soni L. wrote:  what about a dict.setdefaults (note the s) that takes in an iterable or a dict, and uses insert-or-ignore behaviour? (unfortunately a lot of iterables and all generators are hashable, and we can't

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

On Apr 16, 2020, at 07:19, Soni L. wrote: > >  what about a dict.setdefaults (note the s) that takes in an iterable or a > dict, and uses insert-or-ignore behaviour? (unfortunately a lot of iterables > and all generators are hashable, and we can't break that.) > > I could really use

[Python-ideas] Re: Keyword arguments self-assignment

On 4/16/2020 1:30 PM, Rhodri James wrote: On 16/04/2020 17:57, oliveira.rodrig...@gmail.com wrote: @StevenDAprano and this goes for @RhodriJames , thank you for sharing your point of view. Indeed the proposed syntax is obscure and would not be that readable for beginners. Couldn't we work

[Python-ideas] Re: Keyword arguments self-assignment

On 16/04/2020 17:57, oliveira.rodrig...@gmail.com wrote: @StevenDAprano and this goes for @RhodriJames , thank you for sharing your point of view. Indeed the proposed syntax is obscure and would not be that readable for beginners. Couldn't we work around this so? The concept is still good for

[Python-ideas] Re: Keyword arguments self-assignment

I could absolutely see a lot of use for this when it comes to rebinding names in callbacks and the like. for i in range(10): callLater(delay, lambda i=: print(i)) But with this being a very common scenario for such a feature being needed, we'd see a lot of confusion with how much that looks

[Python-ideas] Re: Keyword arguments self-assignment

@ > Do any other languages already have this feature? JavaScript ES6 has similar feature: ```javascript x = 1 y = 2 do_something({ x, y }) ``` ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to

[Python-ideas] Re: Keyword arguments self-assignment

@StevenDAprano and this goes for @RhodriJames , thank you for sharing your point of view. Indeed the proposed syntax is obscure and would not be that readable for beginners. Couldn't we work around this so? The concept is still good for me just the syntax that is obscure, maybe something like

[Python-ideas] Re: Keyword arguments self-assignment

Here's a similar thread: https://mail.python.org/archives/list/python-ideas@python.org/thread/SQKZ273MYAY5WNIQRGEDLYTKVORVKNEZ/#LXMU22F63VPCF7CMQ4OQRH2CG6H7WCQ6 Personally I write code like this all the time and would love this feature, but I can see how it would be a mess for beginners to

[Python-ideas] Re: Keyword arguments self-assignment

Thanks for pointing the previous discussion @ChristopherBarker Proposals are similar but the scope here is limited to function calls which does prevent a bunch of issues already pointed out in the previous discussion. ___ Python-ideas mailing list --

[Python-ideas] Re: Keyword arguments self-assignment

Do any other languages already have this feature? Can you show some actual real-life code that would benefit from this, as opposed to pretend code like: foo(bar=, qux=) I think that if I had seen this syntax as a beginner, I would have had absolutely no idea how to interpret it. I

[Python-ideas] Re: Keyword arguments self-assignment

This (or something really similar) has been brought up recently on this list. Please go look for that, and see how it was resolved at the time. But for now: -1 -- this is not THAT common a pattern, and to the extent that it is, this would encourage people to over-use it, and lead to errors. I

[Python-ideas] Re: Should dataclass init call super?

On Wed, Apr 15, 2020 at 3:36 PM Eric V. Smith wrote: > In general, it's not possible to know how to call super.__init__() if you > don't a priori know the arguments it takes. That's why dataclasses doesn't > guess. The only general-purpose way to do it is to use *args and **kwargs. > I was

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

On 2020-04-16 11:43 a.m., Steven D'Aprano wrote: On Thu, Apr 16, 2020 at 11:17:33AM -0300, Soni L. wrote: > what about a dict.setdefaults (note the s) Do you have any idea of how much confusion and many silent errors will be caused by having methods setdefault and setdefaults on the same

[Python-ideas] Re: Keyword arguments self-assignment

On 16/04/2020 16:23, oliveira.rodrig...@gmail.com wrote: I'm opening this thread to discuss and collect feedback on a language change to support keyword arguments to be self-assigned using variables names. Proposal Taking the syntax from

[Python-ideas] Keyword arguments self-assignment

I'm opening this thread to discuss and collect feedback on a language change to support keyword arguments to be self-assigned using variables names. Proposal Taking the syntax from [bpo-36817](https://bugs.python.org/issue36817) which just [made it to Python

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

On Thu, Apr 16, 2020 at 11:17:33AM -0300, Soni L. wrote: > what about a dict.setdefaults (note the s) Do you have any idea of how much confusion and many silent errors will be caused by having methods setdefault and setdefaults on the same class? -- Steven

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

what about a dict.setdefaults (note the s) that takes in an iterable or a dict, and uses insert-or-ignore behaviour? (unfortunately a lot of iterables and all generators are hashable, and we can't break that.) I could really use something like that tbh. On 2020-04-16 9:47 a.m., Alex Hall

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

I just tried playing with this idea: from collections import UserDict class InsertOrIgnoreDict(UserDict): __setitem__ = UserDict.setdefault print(InsertOrIgnoreDict([(1, 2), (3, 4)])) It caused an infinite chain of exceptions: Traceback (most recent call last): File

[Python-ideas] collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

currently dicts have insert-or-update semantics, e.g.: >>> dict([((), 1), ((), 2)]) {(): 2} this is fine. however, in many cases insert or insert-or-ignore are more useful: (hypothetical examples) >>> InsertOrIgnoreDict([((), 1), ((), 2)]) {(): 1} >>> InsertDict([((), 1), ((), 2)])

[Python-ideas] Re: TLS session resumption

Ander: personally, I would be +1 on the proposed improvement, but someone needs to submit a PR (and of course it has to be reviewed then :-)). I have a (dirty) patch that partially works :-) But I wanted to gather some feedback from this list before I think of finishing and submitting it.

[Python-ideas] Re: Should dataclass init call super?

On 4/14/2020 7:34 PM, Christopher Barker wrote: On Mon, Apr 13, 2020 at 9:22 PM Neil Girdhar > wrote: Cool, thanks for doing the relevant research. For my part, I'd like to see an aeefort to move dataclasses forward. Now that they are in the standard

[Python-ideas] Re: TLS session resumption

On Thu, 16 Apr 2020 05:07:15 +1000 Chris Angelico wrote: > On Thu, Apr 16, 2020 at 4:55 AM Ander Juaristi wrote: > > TLS session resumption is currently supported, but only within the same > > process. To the best of my knowledge, there is no way to save the TLS > > session to a file to resume

[Python-ideas] Re: TLS session resumption

El 15/4/20 a las 21:07, Chris Angelico escribió: On Thu, Apr 16, 2020 at 4:55 AM Ander Juaristi wrote: TLS session resumption is currently supported, but only within the same process. To the best of my knowledge, there is no way to save the TLS session to a file to resume the TLS session later