On Tue, Apr 21, 2020 at 6:56 PM Alex Hall wrote:
>
> Exposing the AST is probably overkill, but we could probably come up with a
> different way to give Python users easy access to the argument names. For
> example, suppose you could define functions like this:
>
> ```
> foo = 1
> bar = 2
>
> #
On Sun, Apr 19, 2020 at 10:50 PM Alex Hall wrote:
> On Sun, Apr 19, 2020 at 5:59 PM David Mertz wrote:
>
>>
> I think you've missed on alternative. Well, it's a variation on "status
>> quo": Use a silly magic helper function like my Q() or Alex' dict_of() in
>> his sorcery library.
>>
>>
>
On Mon, Apr 20, 2020 at 12:57 PM Steven D'Aprano
wrote:
> On Mon, Apr 20, 2020 at 11:15:32AM +0200, Alex Hall wrote:
> > On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano
> wrote:
> >
> > > On Sun, Apr 19, 2020 at 02:10:21PM +0200, Alex Hall wrote:
> > > > >
> > > > > And notice that there is
On 20.04.20 12:52, Steven D'Aprano wrote:
On Mon, Apr 20, 2020 at 11:15:32AM +0200, Alex Hall wrote:
On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano wrote:
I have an actual, concrete possible enhancement in mind: relaxing the
restriction on parameter order.
What? Do you think that the
> I'm saying that the mode-shift suggestion:
>
> func(arg, name=value,
> *, # change to auto-fill mode
> alpha, beta, gamma,
> )
>
> will rule out any further relaxation on that restriction, and that is a
> point against it. That's a concrete enhancement that we
On Mon, Apr 20, 2020 at 11:15:32AM +0200, Alex Hall wrote:
> On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano wrote:
>
> > 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
On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano wrote:
> 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
On Sun, Apr 19, 2020 at 11:18 PM David Mertz wrote:
> If this were in the library I or my project used, whatever limitations and
> edge cases exist wouldn't really matter. If I REALLY cared about saving a
> few duplicate names in function calls, I could easily include it with the
> knowledge
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:
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
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
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
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]
> ...
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
>
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.
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
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
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
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
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
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
>
> 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]
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,
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
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
>
> 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
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.
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,
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
>
> 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,
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
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.
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
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
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
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
>
> 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
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
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
>
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
out of its way to look deceptively like something else.
f(a, b, c)
On Apr 18, 2020, at 05:16, Alex Hall wrote:
>
> Is there anything else similar in the language? Obviously there are cases
> where the same text has different meanings in different contexts, but I don't
> think you can ever refactor an expression (or text that looks like an
> expression) into
On Sat, Apr 18, 2020 at 5:03 PM Steven D'Aprano wrote:
> On Sat, Apr 18, 2020 at 02:13:51PM +0200, Alex Hall wrote:
>
> > My issue with this, and maybe it's what Andrew is also trying to say, is
> > that it breaks our usual assumptions about composing expressions. `{u,
> v}`
> > is an
On 18.04.20 08:14, Steven D'Aprano wrote:
This proposal is an alternative to Rodrigo's "Keyword arguments
self-assignment" thread.
Rodrigo, please feel free to mine this for useful nuggets in your PEP.
(I don't claim to have invented the syntax -- I think it might have been
Alex Hall?)
> 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.
>
The special syntactic form doesn't bother me that
On Sat, Apr 18, 2020 at 12:19:30PM -0400, David Mertz wrote:
> On Sat, Apr 18, 2020, 8:15 AM Alex Hall wrote:
>
> > Under your proposal, these two programs are both valid syntax with
> > different meanings:
> >
> > (1)
> >
> f(**{u, v})
> >
> > (2)
> >
> x = {u, v}
> > f(**x)
> >
>
> I don't
On Sat, Apr 18, 2020, 8:15 AM Alex Hall wrote:
> Under your proposal, these two programs are both valid syntax with
> different meanings:
>
> (1)
>
f(**{u, v})
>
> (2)
>
x = {u, v}
> f(**x)
>
I don't understand what the meaning of (2) would be. Currently it is a
TypeError... Is that "valid"
On Sun, Apr 19, 2020 at 1:04 AM Steven D'Aprano wrote:
> And one final example:
>
> class C:
> def method(self):
> pass
>
> versus:
>
> def method(self):
> pass
>
> class C:
> method
>
Indeed. However, if you put "method = method", it would
On Sat, Apr 18, 2020 at 02:13:51PM +0200, Alex Hall wrote:
> My issue with this, and maybe it's what Andrew is also trying to say, is
> that it breaks our usual assumptions about composing expressions. `{u, v}`
> is an expression, it represents a set, and it always represents that
> wherever you
On Sat, Apr 18, 2020 at 8:18 AM Steven D'Aprano wrote:
> This proposal is an alternative to Rodrigo's "Keyword arguments
> self-assignment" thread.
>
> Rodrigo, please feel free to mine this for useful nuggets in your PEP.
>
> (I don't claim to have invented the syntax -- I think it might have
On Sat, Apr 18, 2020 at 12:42:10AM -0700, Andrew Barnert wrote:
> > Inside function calls, the syntax
> >
> > **{identifier [, ...]}
> >
> > expands to a set of `identifier=identifier` argument bindings.
> >
> > This will be legal anywhere inside a function call that keyword
> > unpacking
On Apr 17, 2020, at 23:18, Steven D'Aprano wrote:
>
>
> Keyword Unpacking Shortcut
> --
>
> Inside function calls, the syntax
>
> **{identifier [, ...]}
>
> expands to a set of `identifier=identifier` argument bindings.
>
> This will be legal anywhere inside a
51 matches
Mail list logo
