[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 11:40 PM Steven D'Aprano wrote: def M(*vals): # ... magic stuff ... return dct > py> alpha = 'something' > py> M(alpha) > Traceback (most recent call last): > File "", line 1, in > File "", line 5, in M > TypeError:

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

On 20/04/20 2:57 pm, Steven D'Aprano wrote: process_files(delete=obsolete_files, archive=irrelevent_files) process_files(archive=obsolete_files, delete=irrelevent_files) That's not a use case for the proposed feature. The intended use cases are more like def

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020, 10:16 PM Steven D'Aprano wrote: > > Understand that I'm not really advocating for a magic function like > Q(). I > > think it's important to keep in mind that anyone COULD create such a > thing > > for 20 years, and very few people bothered to. > > You don't really know

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 10:50:55PM +0200, Alex Hall wrote: > I think I'm uniquely qualified to say with certainty that this is 100% not > true. A basic version like Q("email firstname lastname") like you wrote is > indeed easy to do correctly, but I've said why I wouldn't want to use it > and I

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Mon, Apr 20, 2020 at 1:39 PM Steven D'Aprano wrote: > I'm also looking at that call to eval and wondering if someone smarter > than me can use that to trick me into evaluating something I don't like. > I'm very confused by that call. It appears to be evaluating a bare name in a specific

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 04:14:51PM -0400, David Mertz wrote: > Per your wish, Eric, the glorious successor of Q() ... named M(): > > >>> def M(*vals): > ... import sys > ... import inspect > ... caller = sys._getframe(1) > ... call = inspect.stack()[1].code_context[0] > ...

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

Steven D'Aprano wrote: > 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 firstly > justify that a change is needed, and only then justify a specific > response to that need. [snip] > If you

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

On Sun, Apr 19, 2020 at 06:06:50PM +0200, Alex Hall wrote: > > > > >> function(*, dunder, invert, private, meta, ignorecase) > > >> > > > > > > > > > No reader will ever have to think about the difference. They will simply > > > see the second version and know which arguments are being

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 02:34:35PM -0400, Eric V. Smith wrote: > I'd be only -0.5 on any proposal from this thread (as opposed to -1000 > as I am now) if it were more general purpose than just function calls. [...] > My point is: We already have a way to pass the items in a dictionary as >

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On 20/04/20 1:36 pm, Steven D'Aprano wrote: **{alpha, beta, gamma} **{:alpha, :beta, :gamma} *, alpha, beta, gamma **, alpha, beta, gamma alpha=, beta=, gamma= although I may have missed some. I'm not seeing "much" difference in complexity between them, syntax-wise.

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 11:58:01AM -0400, David Mertz wrote: > Understand that I'm not really advocating for a magic function like Q(). I > think it's important to keep in mind that anyone COULD create such a thing > for 20 years, and very few people bothered to. You don't really know how many

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Mon, Apr 20, 2020 at 02:50:53AM +1200, Greg Ewing wrote: > On 19/04/20 6:58 pm, Steven D'Aprano wrote: > >There are three tokens there: `**{`, an identifier, and `}`. Adding an > >optional comma makes four. > > > >If this is your idea of "complicated syntax", I cannot imagine how you > >cope

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

On Sun, Apr 19, 2020 at 09:28:28AM -0400, Eric V. Smith wrote: [...] > >This will cause a slight reduction in readability of code, as cases of > >foo = phoo, start to stand out and get changed to just foo (by renaming > >the variable phoo). It is a natural outcome of you get what you make >

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

David Mertz wrote: > [...] Many of the new syntax ideas COULD be done with an > arcane function that only needs to be written once (but better than my 15 > minute versions). The fact that such magic functions are not in widespread > use, to my mind, argues quite strongly against them actually

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 02:10:21PM +0200, Alex Hall wrote: > > > > And notice that there is absolutely no difficulty with some future > > enhancement to allow positional arguments after keyword arguments. > > > > We've already discussed in this thread that we shouldn't fear conflicting > with

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

Nope, that's fine. I reckon it's reasonable to call this inspecting the source code. I thought from your GH issue that you meant you read in a whole module of code. I don't want my Q(), or M(), or whatever letter comes after that, in the standard library. I don't even care about making a repo

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 11:00 PM David Mertz wrote: > See this thread where I created M() as successor of Q(). > >> I saw, and I mentioned it: I see you've tried while I wrote this, and it's pretty clear it's very far > from robust. It's really not that hard, I don't think. Probably there are

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

> > Per your wish, Eric, the glorious successor of Q() ... named M(): > > >>> def M(*vals): > ... import sys > ... import inspect > ... caller = sys._getframe(1) > ... call = inspect.stack()[1].code_context[0] > ... _, call = call.split('M(') > ... call = call.strip()[:-1]

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

See this thread where I created M() as successor of Q(). It's really not that hard, I don't think. Probably there are edge cars I haven't addressed, but it's hardly intractable. On Sun, Apr 19, 2020, 4:51 PM Alex Hall wrote: > On Sun, Apr 19, 2020 at 5:59 PM David Mertz wrote: > >> On Sun,

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 5:59 PM David Mertz wrote: > On Sun, Apr 19, 2020 at 7:00 AM Chris Angelico wrote: > >> Yes, exactly. One strike doesn't mean it's out, and with a proposal >> like this, it's a matter of looking at a whole lot of imperfect >> alternatives and seeing which tradeoffs we

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 2:37 PM Eric V. Smith wrote: > So, if M() existed, you could say: > > d = M(telephone, name) > func(**d) > > or > > func(**M(telephone, name)) > Per your wish, Eric, the glorious successor of Q() ... named M(): >>> def M(*vals): ... import sys ... import inspect

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

On 19/04/2020 17:06, Alex Hall wrote: function(*, dunder, invert, private, meta, ignorecase) No reader will ever have to think about the difference. They will simply see the second version and know which arguments are being passed. I seem to be immune to this magical knowledge.

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

> > So, if M() existed, you could say: > > d = M(telephone, name) > func(**d) > > or > > func(**M(telephone, name)) > > Or, you could just use "d" from the first example for your own purposes > unrelated to function calling. > My point is: We already have a way to pass the items in a dictionary as

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

On Sun, Apr 19, 2020 at 7:06 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Alex Hall writes: > > > OK, that's fair. What about `{foo::}`? > > I don't like any of them. People who are going to use the syntax > should choose it, not those of us who won't. > First of all,

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On 4/18/2020 2:03 PM, David Mertz wrote: > f(**{u, v}) I think a fundamental point is that `**{identifier}` looks like you are applying `**` unpacking to a set, but you actually aren't, it is a special syntactic form. If that disturbs you, I'm not going to say you are wrong.

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

Alex Hall writes: > OK, that's fair. What about `{foo::}`? I don't like any of them. People who are going to use the syntax should choose it, not those of us who won't. > I would personally be quite happy if I could replace: > > ``` > class A: > def __init__(self, foo, bar, spam):

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

On 4/19/20 12:04 PM, David Mertz wrote: > > Sure.  But what I gave was a simple case.  There are all kinds of > complications like this person_record being passed around from call to > call without actually accessing `.telephone` in a particular scope.  > Or doing something dynamic with the

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

> And we're done, the problem is solved, and no new syntax is needed. > > > That's bad, and we should discourage that. Encouraging people to safely > pass named arguments instead of abusing positional arguments would improve > the readability and correctness of code overall. > I have nothing

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

> > >> function(*, dunder, invert, private, meta, ignorecase) > >> > > > > > > No reader will ever have to think about the difference. They will simply > > see the second version and know which arguments are being passed. > > I seem to be immune to this magical knowledge. > Sorry, what? How

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

On Sun, Apr 19, 2020 at 11:54 AM Richard Damon wrote: > > When it comes time to refactor—now we need to rename 'telephone' as > > 'home_phone' and add 'cell_phone'—finding all the locations to change > > is a PITA. If only we could grep 'person_record' globally, it would > > have been easy. > >

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 7:00 AM Chris Angelico wrote: > Yes, exactly. One strike doesn't mean it's out, and with a proposal > like this, it's a matter of looking at a whole lot of imperfect > alternatives and seeing which tradeoffs we want to go with. (And > status quo is one such alternative,

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

On 4/19/20 11:28 AM, David Mertz wrote: > On Sun, Apr 19, 2020, 7:24 AM Richard Damon > wrote: > > One of the key motivations of this proposal is to make nicer a > call with a lot of key word arguments where the local > variable name happens

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

On Sun, Apr 19, 2020, 7:24 AM Richard Damon wrote: > One of the key motivations of this proposal is to make nicer a call with a > lot of key word arguments where the local variable name happens > (intentionally) to match the keyword parameter name. I think Stephen said that this "same name

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On 19/04/20 6:58 pm, Steven D'Aprano wrote: There are three tokens there: `**{`, an identifier, and `}`. Adding an optional comma makes four. If this is your idea of "complicated syntax", I cannot imagine how you cope with function definitions in their full generality: What I mean is that

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

On 4/19/2020 7:23 AM, Richard Damon wrote: On 4/19/20 1:48 AM, Stephen J. Turnbull wrote: Chris Angelico writes: > Except that render_template isn't one of my own functions. It's part > of the templating engine (this is a Flask web app). There is no > refactoring to do - that IS the

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

> > And notice that there is absolutely no difficulty with some future > enhancement to allow positional arguments after keyword arguments. > We've already discussed in this thread that we shouldn't fear conflicting with other (real or hypothetical) proposals, even if they're likely. As I see it,

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On 19.04.20 12:57, Steven D'Aprano wrote: On Sat, Apr 18, 2020 at 09:13:44PM +0200, Dominik Vilsmeier wrote:     func(foo, **, bar)  vs.  func(foo, **{bar}) It's still a mode switch, only the beginning and end markers have changed. Instead of `**,` (or `**mapping,`) we then

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 12:09:54PM +0200, Alex Hall wrote: > > Please read what I said again, because that's a mischaracterisation of > > what I said. > > I don't think it is. You said 'it ought to be something "like" an > expression', and then that actually being an expression is not essential.

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

On 4/19/20 1:48 AM, Stephen J. Turnbull wrote: > Chris Angelico writes: > > > Except that render_template isn't one of my own functions. It's part > > of the templating engine (this is a Flask web app). There is no > > refactoring to do - that IS the correct way to call it. > > So NOW you tell

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sat, Apr 18, 2020 at 09:13:44PM +0200, Dominik Vilsmeier wrote: > >     func(foo, **, bar)  vs.  func(foo, **{bar}) > > It's still a mode switch, only the beginning and end markers have > changed. Instead of `**,` (or `**mapping,`) we then have `**{` as the > opening marker

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 5:46 PM Steven D'Aprano wrote: > > On Sun, Apr 19, 2020 at 01:24:14AM +1000, Chris Angelico wrote: > > [...] > > Alex referred to refactoring "text that looks like an expression", and > > on that point, I absolutely agree with Steven here: there are MANY > > places where

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

On Sun, Apr 19, 2020 at 7:58 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Alex Hall writes: > > > > And now Lisp bites me, because '::a' means ... > > > And a single colon also means something else in Lisp. > > Yeah, and I already pointed that out myself in this

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 11:49 AM Steven D'Aprano wrote: > On Sun, Apr 19, 2020 at 10:19:41AM +0200, Alex Hall wrote: > > > But the problem here is not that your proposal doesn't meet all the > > requirements, it's that you have different requirements from us. You are > > requiring something that

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 10:19:41AM +0200, Alex Hall wrote: > But the problem here is not that your proposal doesn't meet all the > requirements, it's that you have different requirements from us. You are > requiring something that looks like an expression even if it isn't. Please read what I

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

> > It would be good if we had something that was neither excessive verbose > nor painfully terse, required nothing but ASCII, that was similar enough > to dict unpacking to suggest a connection, but without being confusable > to anything else even to newbies, was self-descriptive without needing

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 01:24:14AM +1000, Chris Angelico wrote: [...] > Alex referred to refactoring "text that looks like an expression", and > on that point, I absolutely agree with Steven here: there are MANY > places where "text that looks like an expression" can have vastly > different

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 02:30:21PM +1200, Greg Ewing wrote: > On 19/04/20 7:17 am, Alex Hall wrote: > >there > >is something about all these examples (plausibility?) that feels > >distinctly different from your proposal. > > To me it seems like an unnecessarily complicated syntax that goes >

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

Alex Hall writes: > > And now Lisp bites me, because '::a' means ... > And a single colon also means something else in Lisp. Yeah, and I already pointed that out myself in this subthread. I don't like these notations, and the conflict with Lisp (which I read a lot of) is part of why. My